Gradle Version: 2.14.1
Operating System: Windows 8.1
Is this a regression? If yes, which version of Gradle do you know it last worked for? Unknown
I’m using the Gradle Buildship integration in Eclipse. For a while, everything was working fine. But starting yesterday, Buildship stopped resolving external dependencies. In particular, when I restart the daemon the first attempt to resolve external dependencies works. But all subsequent attempts fail to resolve.
The only work around I’ve found is to stop the Gradle daemon before every Gradle operation.
Has anybody seen this issue before?
I created a new project and tried it out and I’m not seeing the same problem. Seems the problem is specific to my project. Currently trying to create a project that reproduces the problem that I can share here.
Let us know what you find and report back to us either way so we can ensure this is resolved.
Turned out to be a somewhat obscure problem. It had to do with the
Artifactory plugin by JFrog. In our build, we were resolving the latest
version of the plugin (version: +), but for one of its dependencies we were
resolving a particular version. And this was causing a version conflict of
some sort resulting in dependency resolution failing. The issue started
when the plugin was updated in our repository and our build started
resolving the newer version.
I’m glad the problem is resolved, but it seems there may still be a Gradle bug here and I’d like to squash it if possible.
A couple answer to these questions would help me:
- Does this issue still occur on the latest Artifactory Plugin and Gradle (3.0) version?
- Do you know the versions of the Artifactory Plugin involved?
- Did you simply downgrade the Artifactory plugin to fix this?
Here’s the actual code that was causing the problem:
apply plugin: “com.jfrog.artifactory”
This was working when I first implemented it. But after one of the
deps was upgraded in the repo, resolution stopped working. When I replaced
it with this it started working again:
id “com.jfrog.artifactory” version “4.4.0”
I think the first code was mixing 4.4.1 with 4.4.0, but I’m not sure. So
to answer your question, I guess I did ‘downgrade’ to 4.4.0 since I knew it
worked. I don’t think everything I needed was in the repo for 4.4.1 (which
caused the mismatch) so it wasn’t really an option.
I haven’t had a chance to try any of this under Gradle 3.0. It had not
been officially released at the time. Soon I should be testing our build
under 3.0, so I might get a chance to try it out in the near future.
Awesome, thanks for your answers.