[GRADLE-2933] Use case for custom ivy resolvers (marked as deprecated for 2.x) Created: 24/Oct/13  Updated: 10/Nov/13  Resolved: 10/Nov/13

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

Type: Task
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Duplicate Votes: 0

Issue Links:
Duplicate
Duplicated by GRADLE-2934 Use case for custom ivy resolvers (ma... Resolved

 Description   

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 ([1]https://github.com/sbrabec/ivyp4) which has many benefits over the "traditional" separation of source and binary repositories:

1. 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 The more data sources we have for a build, the harder it is to reproduce e.g. a release build from 5 years ago.
4. 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.
----------------------------------------------------------------------------------------
[1] https://github.com/sbrabec/ivyp4


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