[GRADLE-3097] Dynamic dependency resolves to a snapshot instead of the latest release Created: 31/May/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 10


My team develops our own internal Gradle plugin which we release on our own Artifactory repository. Intermediate builds are published as snapshots with a name like OurPlugin and version 0.9.5-SNAPSHOT.

(Currently using Gradle 1.10, but saw the same result with 1.12)

In our build.gradle scripts, we apply our plugin, with dependencies declared like this

buildscript {
repositories {
maven {
url "http://ourRepo"
dependencies {
classpath(group: 'ourgroupid', name: 'OurPlugin', version: '0.9.+')

The problem I'm seeing is that if I've got a release out with version 0.9.4, and a snapshot 0.9.5-SNAPSHOT, then Gradle scripts always uses the snapshot. If I then make 0.9.5 official and release it, then the Gradle uses it instead.

What am I missing here, or is this a bug?

Comment by Gradle Forums [ 31/May/14 ]

We also publish custom plugins, and put them on the classpath with a dynamic version specification.

We publish snapshots to one repo, and releases to another repo. By default in all the projects, the build script repositories block specifies only the release repo. So snapshots are not picked up.

You could declare the snapshot repo also, but wrap it in a conditional based on a project property. Then you can control whether or not a build uses snapshots, and what the default is. We don't happen to do this, but it would certainly be possible. Or if you never want the snapshots, don't bother declaring that repo at all.

Comment by Gradle Forums [ 31/May/14 ]

So it looks like having one repo for both snapshots and releases is just a bad practice. I'll need to separate them out, or just stop publishing snapshots.

Comment by Gradle Forums [ 31/May/14 ]

Looks like a bug to me. Can you try with an older version (say 1.8 or 1.6)?

Comment by Gradle Forums [ 31/May/14 ]

I've tried with 1.8, 1.6, and even 1.0. They all use the snapshot. I'm wondering if snapshots are used, since their pom files show versions made with timestamps like this:


Comment by Andreas Schopper [ 20/Feb/15 ]

We have the same problem after we switched from Gradle 1.10 to Gradle 2.2.1.

This strange behavior was introduced with Gradle 1.12.

We uses dynamic version a lot for core libraries and for us this is a serious problem.

Is there a workaround?

Comment by Francisco Lozano [ 01/Aug/15 ]

This is quite a surprise, and a blocker for me. Any workaround would be appreciated.

Comment by Andrea Di Giorgi [ 06/Sep/16 ]

If anyone is interested, I wrote a workaround which should work in the latest versions of Gradle: https://gist.github.com/Ithildir/b2fb163216d6dd96ca29c304bb2f3ce9

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:39:52 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.