apiとimplementation の自メモ
動作環境
はじめに
検証用の記事。あとで追記する予定
書き換えるにあたって参考にするといいと話題になってたスライド
高速化Tips1:最新pluginを使えの話
下記2つが Tips-1の言及内容根拠らしい。
Gradle plugin 3.0: ABIの概念が登場。non-ABI changesは依存ライブラリチェインで再ビルドをトリガーしない。C#でも同じものが入ったばかりだね。
— Atsushi Eno (@atsushieno) 2017年5月19日
こっちは、FlavorとかABI とかあんまり使わないのでアレかな・・とかは思う*1
'compile' is now deprecated. Replace with 'api' or 'implementation' // えー…
— Atsushi Eno (@atsushieno) 2017年5月19日
api を変更したら依存する側のプロジェクトが全部再ビルドされる。implementationを変更してもそれは起こらない。
— Atsushi Eno (@atsushieno) 2017年5月19日
ドキュメントにあまりちゃんと書いてないので、G様利用サンプル待ちかもな・・
dependenciesで apiとimplementation が宣言してくれという話
gradle runtime 3.5以上から android gradle plugin のベースになっている
java plugin の DSL にプロパティが追加されていて
そっちを使ったほうが、gradle runtimeの最適化対応に対応できるという話みたい。
そのサポートがAS3.0のpluginから対応するみたいな事のよう
The Java Library Plugin - Gradle User Guide Version 3.5
公式ドキュメント
Migrate to the New Plugin | Android Studio
らしい
エラーになってたファイル名変更タスク
横から失礼します。下記の対応をしようと思ってエラーになってしまいコメントにして触っているのですが、なんかいい方法あったりしますでしょうか? https://t.co/hi30UDFENt
— close_yutori (@kimukou2628) 2017年5月20日
AS2.3/AS2.4 では動いているのですが、AS3.0のgradle pluginに変更した段階で outputFileなメンバーはないよ! と怒られてしまうのですorz
— close_yutori (@kimukou2628) 2017年5月20日
確かに println output.dump() するとそんな変数は見当たらず
ありがとうございます。そのページの一番下の [API change in variant output] あたりでできそうな気がします。あとで試してみます。
— close_yutori (@kimukou2628) 2017年5月20日
- app/build.gradle
android { applicationVariants.all { variant -> if (variant.buildType.name.equals("release")) { variant.outputs.each { output -> if (output.outputFile != null && output.outputFile.name.endsWith('.apk')) { // Rename APK def applicationId = defaultConfig.applicationId def versionCode = defaultConfig.versionCode def versionName = defaultConfig.versionName def date = new java.text.SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date()) def newName = "${applicationId}_r${versionCode}_v${versionName}_${date}.apk" output.outputFile = new File(output.outputFile.parent, newName) } } } } }
=>
- app/build.gradle
android { android.applicationVariants.all { variant -> if (variant.buildType.name.equals("release")) { variant.outputs.all { // outputFileName = "${variant.name}-${variant.versionName}.apk" // Rename APK def applicationId = defaultConfig.applicationId def versionCode = defaultConfig.versionCode def versionName = defaultConfig.versionName def date = new java.text.SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date()) outputFileName = "${applicationId}_r${versionCode}_v${versionName}_${date}.apk" } } } }
試行状況
これ自分も試してみたんだけど、結構厳しくて置き換え挫折した。
小さいプロジェクトならいいんですけどライブラリ使いまくっていると厳しいかな。
- data-binding &APTてんこ盛り環境だと、
- plugin差し替えだけで意味がわからないエラーが多発したので
- 上記の記事に書いているように依存解決(exclude)辺にあたるものが不明なため
- 依存ライブラリが重なるとエラー解消が無理
もうちょっと追跡調査が必要な気がする
TLメモ
AS3.0でretrolambdaが使えなくなり、retrolambdaを使用してビルドしてたライブラリが " java.lang.NoSuchMethodError: No static method" で死んだので、マイグレーションが死にそう
— 川峠@Andriders (@eaglesakura) 2017年5月19日
AS3.0でAndroid App -> Android Lib Prj -> Java Lib Prjみたいに階層が複雑なプロジェクトだと依存関係が解決できない・・・?
— 川峠@Andriders (@eaglesakura) 2017年5月20日
Googleさぁぁああん!!
— 川峠@Andriders (@eaglesakura) 2017年5月20日
compileからimplementationに変えるとJavaプロジェクトとしてビルドしたライブラリが依存解決されないのでございまぁあああぁあぁああす!!
職人が1件1件jarとaarをチェックするのでございまぁあああああああす!!!
— 川峠@Andriders (@eaglesakura) 2017年5月20日
条件が面倒で、implementation project(hoge)をした場合で、そのプロジェクトがjarをimplementationするとプロジェクト全体を巻き込んで依存解決できないらし
— 川峠@Andriders (@eaglesakura) 2017年5月20日
もしかして、どういう条件か知らんが2階層以上依存しているライブラリプロジェクトを認識できてないんじゃねかな
— 川峠@Andriders (@eaglesakura) 2017年5月20日
もしかして、どういう条件か知らんが2階層以上依存しているライブラリプロジェクトを認識できてないんじゃねかな
— 川峠@Andriders (@eaglesakura) 2017年5月20日
依存してるGuavaのバージョン競合が解決できないので、Slack通知Pluginが死亡した
— 川峠@Andriders (@eaglesakura) 2017年5月20日
dataBinding = trueにした状態でdataBindingを未使用だと問答無用でコンパイルエラーになる。
— 川峠@Andriders (@eaglesakura) 2017年5月20日
たぶんバグ。
踏み抜いた。
というか、自分の環境だと`org.gradle.caching=true` でreleaseビルドしようとするとdataBindingのソースコード変換でNPEが出て失敗するので、CIでは殺してあげる
— 川峠@Andriders (@eaglesakura) 2017年5月22日
gradlew assembleXXX
系をすると駄目。つまりInstantRun OFFにするとビルド不可。
さすがG様クオリティ・・
- AS2.4p6あたりマージされているようなので、
- 本来ならビルドできるんだろうけどなー
- p7あたりがdata-binding(というかAPTの)ビルドが怪しかったのでそこら辺がマージされているのかも
*1:開発時にエミュだけ使うとかあんまりありえないし・・