Up-to-date check for changing external dependencies


(david koch) #1

Hello, I have changing external dependencies in my project. When building the project I noticed that when the dependency is re-downloaded Gradle signals on command line output that all tasks are up-to-date.

I would have expected that if a dependency changes the task is not up-to-date since a major input has changed and may cause build errors. Same behavior I see on changes to the build script itself. Shouldn’t it make also make the up-to-date check resulting in not up-to-date? Thanks, David


(Peter Niederwieser) #2

If the downloaded artifact turns out to have the same content as the one that was used previously, there is no need to rerun any tasks. Likewise, if the build script changed but the configuration values for a particular task stayed the same, that task doesn’t have to be rerun.


(david koch) #3

Do I understand it right that gradle checks whether the class files of the jar have changed in order to determine up-to-date state?

So probably the build timestamp in the jars manifest causes the sha1 hash of the jar to change. Which causes gradle to re-download the jar dependency. But than gradle knows non of the class files contained in the jar changed since the former build so recompilation isn’t required?


(Peter Niederwieser) #4

Gradle’s up-to-date check is a generic feature. A task will be executed again if any of its inputs changed, or its output is no longer available or has been tampered with. You can read more about this in the user guide.

Your hypothesis of what happens in your particular situation sounds plausible.


(david koch) #5

I’ve tried to fiddle this out for me. I’ve two separate Java/Gradle (milestone8a) projects A and B. B has a compile dependency on A. A is a changing module.

Now I did the following: - build/upload A

  • build B (downloads A) - remove a java class from A which is required to properly compile B - build/upload A - build B (downloads modified A, reports all tasks are UP-TO-DATE)

My observation is that after downloading a changed dependency gradle ignores this change. In my case B should have be compiled and failed. But compilation was skipped because it was seen as UP-TO-DATE. The build was successful but should have failed.


(Luke Daley) #6

By default, changing modules are cached for 24 hours and not checked for updates.

Are you sure Gradle downloaded the new “A”?


(david koch) #7

Sorry my fault. The output is:

:compileJava

Download http://…

:compileJava UP-TO-DATE

But if the change really breaks the build gradle performs well and lets the build fail. Great feature, Thanks a lot