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.

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.

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

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:

<version>0.9.5-20140530.132746-1</version>

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?

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

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

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!

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.