WAI
Status Update
Comments
ma...@gmail.com <ma...@gmail.com> #3
I have read that page. Only mentions of compileOnly configurations are that they replace old provided configuration.
I can't find anything there that would explain why Android dependencies do not support compileOnly.
I can't find anything there that would explain why Android dependencies do not support compileOnly.
uc...@google.com <uc...@google.com> #4
can you share a sample project to reproduce this issue.
ma...@gmail.com <ma...@gmail.com> #5
Attaching. Either opening in Android Studio or just compiling directly from command line will result in a build failure.
uc...@google.com <uc...@google.com> #6
* What went wrong:
Execution failed for task ':app:preDebugBuild'.
> Android dependency 'com.android.support:recyclerview-v7:27.1.0' is set to compileOnly/provided which is not supported
Reproduced in
Android Studio 3.1 RC 1
Build #AI-173.4625007, built on February 27, 2018
JRE: 1.8.0_152-release-1024-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.9.0-6-amd64
Execution failed for task ':app:preDebugBuild'.
> Android dependency 'com.android.support:recyclerview-v7:27.1.0' is set to compileOnly/provided which is not supported
Reproduced in
Android Studio 3.1 RC 1
Build #AI-173.4625007, built on February 27, 2018
JRE: 1.8.0_152-release-1024-b01 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Linux 4.9.0-6-amd64
je...@google.com <je...@google.com> #7
this is working as intended, you cannot have compileOnly aar files, you can only have compileOnly jar files.
minifying should take care of your use case, eliminating code that's not reachable.
minifying should take care of your use case, eliminating code that's not reachable.
ma...@gmail.com <ma...@gmail.com> #8
Yes, I know this is kind of intended behavior. That is why I worded this as feature request to improve that behavior.
Minifying is not the best solution, since it is only supposed to be done on release versions. If method count due to included libraries gets too high, we can:
1. Enable full support multidex, which would make it redundant since release version would not have that many methods
2. Only enable 21+ multidex, which would make it harder to test debug builds on API < 21
3. Enable minifying for debug builds, which would make these builds way too slow
Simply not including redundant libraries seems to be much better option than relying on minifying.
Minifying is not the best solution, since it is only supposed to be done on release versions. If method count due to included libraries gets too high, we can:
1. Enable full support multidex, which would make it redundant since release version would not have that many methods
2. Only enable 21+ multidex, which would make it harder to test debug builds on API < 21
3. Enable minifying for debug builds, which would make these builds way too slow
Simply not including redundant libraries seems to be much better option than relying on minifying.
vi...@gmail.com <vi...@gmail.com> #9
Hi All,
I am also of support that this is unnecessary pre-build check.
We have >30 modules that depend on support-v4 lib.
But we want to make these modules aar smaller, and use include the support-v4 aar in the app module.
This error if really required should be lint warning, or configuration should fail with Gradle. I don't understand why we have to build all 100 apks that we have and also testAndroid apks to find such hidden errors.
Upgrading Gradle should ease developers work not cause massive disruptions that take weeks of debugging to find such issues.
I am also of support that this is unnecessary pre-build check.
We have >30 modules that depend on support-v4 lib.
But we want to make these modules aar smaller, and use include the support-v4 aar in the app module.
This error if really required should be lint warning, or configuration should fail with Gradle. I don't understand why we have to build all 100 apks that we have and also testAndroid apks to find such hidden errors.
Upgrading Gradle should ease developers work not cause massive disruptions that take weeks of debugging to find such issues.
Description
1. Create new blank project
2. Try adding one of the support library modules (for example 'com.android.support:recyclerview-v7:27.1.0') as compileOnly dependency
3. Build will fail
Main use case I see is creating libraries that do not include their dependencies into parent app (in above example I can add some utility methods for RecyclerView into the library, but if parent project does not need RecyclerView, my app will not add runtime classes into app's code for no reason).