Use case for custom ivy resolvers (marked as deprecated for 2.x)

Old Forum Archive
1

Hi all,

there is a demand for custom ivy resolvers, so in my opinion they should be supported in 2.x:

We are using an ivy repository via Perforce (https://github.com/sbrabec/ivyp4) which has many benefits over the “traditional” separation of source and binary repositories:

No additional infrastructure (maven,artifactory,archiva) needed, which saves costs for IT (same backup & restore, same server, same licensing). 2.

Improving the existing infrastructure (like adding replication servers, failover servers, proxy servers) scales for the binary artifacts “for free”. E.g. I use a perforce proxy on my laptop, which also proxies the binaries. 3.

Artifacts are versioned using the same atomic number as the sources, which means: I can easily revert, sync to specific dates, examing the commit logs etc. There is only a single source of truth -> Version everything (Perforce marketing :wink: The more data sources we have for a build, the harder it is to reproduce e.g. a release build from 5 years ago.

Build artifacts are hosted by the CI server (in our case Teamcity, which servers artifacts also via ivy). So there’s no need for an additional artifact server.

So we would appreciate if the custom ivy resolver will be still available in gradle >= 2.x. If it is of any help I could supply a demo project/perforce server showing the setup.

2

It’s unlikely that custom Ivy resolvers will still be supported in 2.x (they are already deprecated today), but perhaps Gradle could offer the necessary hooks for you to integrate with your binary repository (i.e. “custom Gradle resolver”). Raised as GRADLE-2934.

3

The ivy repository interface is basically get, put, and list using a string as the artifact path. With a similar addressing scheme it would be easy to port the ivy resolver to “native” gradle.

4

I wonder if it would be possible to just register a custom protocol like ivyp4:// and use this as the base URL in the IvyArtifactRepository. Should this work or is there any internal stuff that assumes http:// ?

5

Hi Peter,

are there already “hooks” for a custom gradle resolver in 1.10 or 1.11 where we can start porting the ivy stuff ? Thx.