Snapshot compile dependency ends up with different versions in different configurations

Old Forum
1

I have a project P that has a compile dependency on a SNAPSHOT version of a library L. There are different versions of this SNAPSHOT version of L available from an artifactory repository. Each of those have a runtime dependency on another library T, but on different versions. I have set the changing modules cache time to 0 seconds. for all configurations. In the compile configuration of P, T (the transitive library) shows with the newest version, but in the runtime and default configurations, it is listed with an older version.

2

I suspect this might be due to GRADLE-3017, which meant that the cache wasn’t being updated for changing modules. We think this is fixed in Gradle 1.11, which was just released.

Even with the changing module timeout set to 0 seconds, we still use the cache for all but the first resolve of a particular module within a single build. So while the initial ‘compile’ resolve would get the correct version, the cache wouldn’t be updated, and the ‘runtime’ and ‘default’ configurations would be getting the incorrect cached version.

Can you please confirm if this is still a problem with Gradle 1.11?

3

Thanks for the hint, that would explain the behavior. I just tried to update to Gradle 1.11 but the update doesn’t work flawlessly. I get MissingPropertyException on the ext object. In my build file, I declare ext.versions as a map, so I can specify dependencies as “group:module:$ext.versions.modulename”. In Gradle 1.10 that worked fine but in 1.11 I get “cannot get property ‘versions’ on extra properties extension as it does not exist”.

4

Apparently, the semantics of using the ext properties from within the dependencies closure has changed. In Gradle 1.10, $ext accesses project.ext, in 1.11, the dependencies closure seems to have its own ext properties.

5

Thanks for investigating this. This is unintentional. We’ll likely fix this for 1.12. Will post back when we decide on what we are going to do.

6

Just for the record (and for anyone hitting this issue until 1.12 is out): Changing ‘$ext.versions’ to ‘$project.ext.versions’ or, curiously, just ‘$versions’ fixes the issue.

7

Using just $versions works because it effectively walks up the scope hierarchy trying to find something with a ‘versions’ property.