Affects Version/s: 1.0-milestone-3
Fix Version/s: 1.0-milestone-7
Given the following build.gradle in an empty directory:
and the following gradle execution:
we get the following resulting directory structure:
note that we started from an empty directory.
Digging into the gradle source a bit we find the following code:
note among other things the 'temporaryDir' variable access. This comes from a super class a bunch of inheritance levels up:
notice the 'dir.mkdirs()'. So to summarize: just by instantiating the Jar task class we will create the directory structure described above. This is independent of whether we have elected do disable the jar task entirely, excluded it from the execution graph, added an onlyIf clause etc etc.
Note that we get the same result with the following build file:
and just executing 'gradle tasks'.
I think this behavior is unexpected and undesirable. In large multi-project builds where we want to leave directories without sources or resources well alone, this becomes a serious issue.
In addition, creating a clean workaround by selectively deleting the build directory only when it was erroneously created by the jar task is actually non-trivial. How do you figure out if the Jar task erroneously created the directory? And if it did, where do you add the code to remove the directory? jar.doLast doesn't work as (in my specific example) I have disabled the jar task and jar.doLast is therefore not executed. Adding this to assemble.doLast works but gets hairy with the state management to only do this when the jar task did the wrong thing.
As this is really not clean I hesitate to even share this, but perhaps it can help somebody out there. I ended up with the following simplistic workaround:
Can we make all the code after the two first lines in the Jar class constructor get executed on first-run or first-access (of say getMetaInf etc) instead of in the constructor?