Gradle rebuilds unchanged common subprojects

Help/Discuss
1

Hello,

I have two separate Java projects, A at D:\trunk\A and B at D:\trunk\B which both use some common subprojects located in the folder D:\trunk\common\SUBPROJECT1, D:\trunk\common\SUBPROJECT2 etc.

When I perform successive builds without source change of project A, all tasks performing builds of common subprojects are up-to-date and gradle does not execute them.

However, when I perform the build of project B that was built in the past and has not changed since, some common subprojects get rebuild, despite the fact that no actual changes to the common subprojects were made. Info output for the tasks that are supposedly not up-to-date is:

:SUBPROJECT1:jar (Thread[Daemon worker Thread 5,5,main]) started.
:SUBPROJECT1:jar
Putting task artifact state for task ':SUBPROJECT1:jar' into context took 0.0 secs.
Task :SUBPROJECT1:jar class loader hash: 83f3637f6805a7b149525a93c5faad58
Task :SUBPROJECT1:jar actions class loader hash: fde60ab3b9776111ebd9bf87f24df716
Executing task ':SUBPROJECT1:jar' (up-to-date check took 0.058 secs) due to:
  Output property 'archivePath' file D:\trunk\common\SUBPROJECT1\build\libs\A-9.12.296.jar has changed.

I have output the property ‘archivePath’ of the SUBPROJECT1 when building A and when building B and it hasn’t changed, in both cases it was "D:\trunk\common\SUBPROJECT1\build\libs\SUBPROJECT1-9.12.296.jar"
There are also other tasks in subprojects that are not up-to-date with the reports like:

:SUBPROJECT3:compileJava (Thread[Daemon worker Thread 5,5,main]) started.
:SUBPROJECT3:compileJava
Putting task artifact state for task ':SUBPROJECT3:compileJava' into context took 0.0 secs.
Task :SUBPROJECT3:compileJava class loader hash: 83f3637f6805a7b149525a93c5faad58
Task :SUBPROJECT3:compileJava actions class loader hash: d883a18cf154fc57e90f4d3fa9e5588f
Executing task ':SUBPROJECT3:compileJava' (up-to-date check took 0.062 secs) due to:
  Input property 'classpath' file D:\trunk\common\SUBPROJECT1\build\libs\SUBPROJECT1-9.12.296.jar has changed.

Any ideas, why gradle detects these tasks as not up-to-date, even though the actual properties haven’t changed?

Best regards,
Jurij

2

They are changing because you are including common into completely different builds (A and B), which are using a separate task history. As a result, A overwrites the JAR (same content, but different timestamp), then B considers it out of date and overwrites it again (changing the timestamp again), then A considers it out of date…

Even if that wasn’t the case, there would still be other issues, e.g. A and B might be using different Gradle versions, different plugin versions etc. So you are not really executing common in the same environment and there will be all kinds of reason for it being out of date.

For more isolation you can use composite builds instead of subprojects.

3

Thank you for the quick reply and suggestion. I will definitely check it out.