In 1.0-milestone-7 is it possible to resolve dynamic/changing dependencies based on timestamp?

Old Forum
1

I’ve been trying out a simple demo with 2 projects where project A depends on project B (B is published to a nexus snapshot repository ). The behavior I seem to get is when I try to control the resolution strategy is as follows: when I use { cacheChangingModulesFor 0, ‘minutes’ } the build seems to download (according to the logging) the jar every build. And when I use { cacheChangingModulesFor 1, ‘minutes’ } it doesn’t detect actually updates in repository until one minute has passed.

For the first case it could seem kind of expected but I would expect the build to actually look up if the artifact is actually changing. I would expect this to work the same with dynamic dependencies.

Is it possible to config the resolution to check if the timestamp has been updated in the remote repository rather then just relying on local knowledge?

If it seems that I am misunderstanding the architecture for resolution strategies can you please point me to some reading material on it?

Sorry but here is another related question bundled with the other: Another strange ‘feature’ I’ve come across in m7 is that when querying dynamic modules in nexus it starts by downloading all poms for the module in question (regardless of any version resolution). This is causing a severe performance problem for me since many of the modules I’m querying have 60+ versions available (of all major and minor versions) and the whole lot is downloaded for examination. Is there anyway to just trust the maven-metadata.xml and just download the desired pom?

best regards gretar

2

First up, a disclaimer: there are some issues with changing module handling in Milestone7. Your best bet would be to use a recent nightly build until Milestone8 comes out (very soon).

To your first issue: Gradle has a concept of a ‘changing module’ that is similar in many ways to Maven snapshots. You can read about these here: http://gradle.org/docs/current/userguide/dependency_management.html#sub:dynamic_versions_and_changing_modules.

In a lot of cases, users don’t want the overhead of checking for a new version of a changing module every build. So we enable caching of these modules, by default for 24 hours. In your case, however, you want to check for a new version every time, so you are correctly setting ‘cacheChangingModulesFor 0, ‘minutes’’. (There is not yet a way to specify the cache timeout for particular modules, but it is in the works).

To avoid actually downloading the artifact every time, Gradle will check for a published .sha1 file in the remote repository and compare it against the checksum of the cached artifact. So publishing checksum files will help. Gradle does not (yet) check timestamps of remote artifacts to prevent download.

3

Can you please ask your second question in a separate forum post? It helps make the forum more searchable and structured. (Even better if you edit this post to remove the second question as well!)

4

Here is some documentation on the Gradle dependency cache: http://gradle.org/docs/nightly/userguide/dependency_management.html#sec:dependency_cache This will be part of the official docs as of Milestone8.

5

Thanks Daz, for swift and good answer. Sorry for the second question, I was tired at the time and should have known better :). Regarding editing this question, I haven’t quite figured out how to edit the question.

I’ll try uploading the checksum file and see the result.

6

Been trying 1.0-milestone-8-20120202000029+0100 for some time, even resorted to set it up on all the buildagents and it has been giving good results so far also performance wise. Best build I’ve tried yet :slight_smile:

I’ll be trying the cacheChangingModulesFor/checksum interaction some more in coming days but I can’t wait till the official release of 1.0m8 so I can upgrade the whole company.

Thanks

7

We’ve just merged M8 into our release branch, you can expect a release candidate in the next 24 hours. We’ll let that sit for a few days to see if any major problems are reported, then make it an official release.