Closed gamerson closed 8 years ago
There is a good chance that this issue will also be fixed with https://github.com/TomDmitriev/gradle-bundle-plugin/issues/51 I'll give it a try
Thanks for the demo! Compilation of impl module is triggered when api.jar is changed, which happens because META-INF/MANIFEST.MF inside api.jar is changed, which in turn happens due to the fact that tstamp
is updated. That is the way Gradle works with or without this plugin, so this part is not surprising. The perplexing part is why compilation sometimes fails complaining about corrupted api.jar. I have checked that the file does exist and if the daemon is killed and started again :impl:compileJava becomes successful without re-writing api.jar, so its content does not seem to have anything to do with the problem. Without deeper and, I fear, quite-time consuming investigation I suggest as a work-around running compilation in a separate process, which seems to fix the issue, i. e.
subprojects {
...
compileJava {
options.fork = true
}
}
(v0.8.1 is required)
so even with fix in #51 applied it still happens but I can confirm that setting compiler.fork = true does fix the issue for me, so I can consider this one closed.
Take this sample project uploaded here: https://github.com/gamerson/daemon-compiler-failure
This project has 2 simple bundles built using DM plugin. And "api" and "impl". When rebuilding the impl jar using "gradlew --daemon jar" you can see eventual failures in the gradle compileJava task just by re-running the same command with no change to the source files. Here is the error that is shown:
In the repo I linked to I have the full reproduce steps. The way to fix the error is to simply drop off the "${tstamp}" variable in the bundle instruction. I suppose that ${tstamp} variable expansion by bndlib is throwing off the manifest 'out-of-date' calculation someway. But of course the worst case scenario is that gradle just reruns the "api:jar" task when it doesn't need to. It should not be throwing the compilerJava task exception.
This never happens if you are not invoking with the daemon. It appears to be a daemon/caching problem that is triggered by the changing manifest hash inside of DM plugin.
Thoughts?