Plugin uses stale outputFile #40
Comments
|
Interesting. I was wondering if we'd see problems from that commit - I guess we do! Thanks for reporting. Can you please post a build script and commandline invocation that reproduces the problem? I'm pretty sure that I've used this kind of apk name rewriting without having this problem in the past, and haven't been able to reproduce it. |
|
Seems to be identical to issue #46, which I can reproduce and confirm. |
benjamin-bader
added a commit
to benjamin-bader/dexcount-gradle-plugin
that referenced
this issue
Jan 26, 2016
This fixes a bug wherein the dexcount task fails if the variant's output is renamed after the dexcount plugin is applied and prior to task execution. This also opts dexcount out of Gradle's incremental compilation cache. The proximate cause of this bug is that we're holding a stale `java.io.File` object; the cure is to instead hold a reference to the variant's output. This doesn't work with incremental compliation, because variant output implementations aren't `Serializable` (noted in KeepSafe#32), and Gradle depends on task state being serializable. This mismatch means that dexcount will appear to randomly crash. The least-bad solution is to just remove the task-input annotation, and run the count task every time. Not great, but better than not working. Fixes KeepSafe#40 and KeepSafe#46.
|
I think this is fixed in the latest snapshot build; would you please try again using 0.4.1-SNAPSHOT and confirm? |
|
Hey @benjamin-bader the 0.4.1-SNAPSHOT seems to work fine for me ;] |
|
Awesome, thanks! |
|
FYI, version 0.4.1 (including this bugfix) is now available in Maven Central, or it will be in an hour or two. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since 0.3.1 (more specifically commit) the outputFile that gets used to report dexcount will be stale if user rewrites apk name with
applicationVariants.all { variant -> ... }logic.The text was updated successfully, but these errors were encountered: