Repository navigation
Fix task order between compileJava and processResources. - #7323
Conversation
|
Thanks for the PR.
I think the answer is in the Example of comment (see the "Expected" headline): #7306 (comment)
I am not so sure, given the problem of #7306 (and if I understand your sentence correctly). Maybe @bjhargrave and @jhanders34 have an opinion. |
My understanding of the example you linked is that the bundle mostly contains classes included from an external jar, but wants to replace one class with a locally compiled version. The test needs the local version to appear before the included one on the classpath, but it wouldn't normally get that, because Gradle normally runs tests against the output of There aren't any compile tasks in the example where the compiler needs to see any resources belonging to the same source set. Even if there were, you could just put them on the buildpath/testpath. |
You are right. Forget my remark. I misinterpreted. |
ccbf425 to
24b3b12
Compare
Both these tasks have the same output directory. If compileJava runs first, which can sometimes happen when cached state is reused, then processResources clears out the output directory when it runs, deleting all the classes. But if processResources runs first, compileJava happily writes classes into the same directory tree without deleting the resources. Signed-off-by: Eleanor Joslin <[email protected]> Signed-off-by: BJ Hargrave <[email protected]>
24b3b12 to
968b11e
Compare
3 participants
Fix for #6896 in the Gradle case only.
Both these tasks have the same output directory. If
compileJavaruns first, which can sometimes happen when cached state is reused, thenprocessResourcesclears out the output directory when it runs, deleting all the classes. But ifprocessResourcesruns first,compileJavahappily writes classes into the same directory tree without deleting the resources.I've done the same thing for the
testsource set.I noticed that when the source sets have extensions for other languages,
BndPluginadds the outputs ofprocessResourcesas inputs to the extraAbstractCompiletasks. This was added recently in #7313. I'm not sure whether this was done to enforce a task ordering dependency or if the inputs are actually needed for some reason. I know that they're not needed for Java compilation, so I opted for a simple ordering between the tasks.I tried to write a test:
doLastblock to thejartask to verify that the jar contained a classcleanandjarto see if the check ever failedUnfortunately I couldn't get the build to ever fail. I think it's because the Gradle Test Kit doesn't use a Gradle daemon in the usual way, so there's no opportunity for the cache to get into a state where it starts changing the task order.