How can gradle be configured to resolve ivy dependencies on a nexus proxy?

(Fred Thiele) #1

We’re struggling with the following issue.

We set up a proxied Nexus pro repository infrastructure. We have a Nexus Master repository and two Nexus Slave repositories. We use proxy functionality, moreover the smart proxy functionality.

We have a multiproject build environment and make use of ivy dependencies with gradle. If nothing goes wrong, the published artifacts are proxied actively (smart proxy can take care of this) to the slaves and can be resolved also using dynamic versions (e.g. ‘1.1.+’). If a network connection is broken or even accessing older releases from the master, that have been published when the slaves where not available, then the resolving of an artifact at the slave doesn’t work as expected.

Expectation would be, that nexus resolves to the most current version on the master and fetches it to the slave. This doesn’t work. We set up a test scenario, where the slave has older versions than the master. Resolving ivy dependencies on the slave never resolves them on the master.

Gradle Documentation says, that ivy and dynamic versions are resolved using directory listings. This obviously isn’t possible on proxy instances.

Has anyone any idea how to cope with that issue?

Thanks, Fred

(Peter Niederwieser) #2

Unlike Maven repositories, Ivy repositories don’t contain metadata files listing available module versions. Instead, directory listings are used to determine which versions are available. If you can’t make directory listings work with Nexus, you can refrain from using dynamic versions, switch your Ivy repositories to Maven repositories, or try another repository server (e.g. Artifactory).

If you do want to solve this on the Gradle side, and aren’t afraid to invest some effort, you could try to use a dependency resolution hook such as ‘configurations.all { resolutionStrategy.eachDependency { … } }’ to query some version database (perhaps leveraging a Nexus REST API) and resolve dynamic version yourself.

(Fred Thiele) #3

We’ll carefully take your suggestion(s) into account. I’ll get back onto this issue later. Thanks.

(Fred Thiele) #4

We currently solved this by implementing a synchronization script, which compares the content of our proxied repositories with those of the main nexus instances and fetches missing artifacts directly using wget > /dev/null on the proxies. Though this seems gory it solves the currently missing functionality on the proxies to support custom layout repositories, where no standard maven GAV-resolution is possible. Thanks so far.