Custom ivy resolver deprecation in gradle 2.x?


(Baiyan Huang) #1

Hi, All,

I’ve heard from this StackOverflow question (http://stackoverflow.com/questions/18964166/custom-ivy-resolver-documentation) about the deprecation of ivy custom resolver in gradle 2.x, as in the first comment of the question:

Be aware that using custom Ivy resolvers will no longer be supported in 2.x.

But I can’t find any official documentation about this - could you please help clarify:

Thanks very much!


Cannot instantiate ivy classes
(Peter Niederwieser) #2

Custom Ivy resolvers have already been deprecated (I believe in 1.7 or 1.8; check the release notes), and will no longer be supported in 2.x. Ivy repositories will still be supported. An example for use of a custom Ivy resolver would be:

repositories {
     add(new org.apache.ivy.plugins.resolver.URLResolver())
 }

If you don’t use this or a similar Ivy resolver class in your build script, no changes will be necessary.


(Baiyan Huang) #3

Cool, thanks Peter, we are using something like:

repositories {
    ivy {
        ivyPattern "/filesytem/repo/[organisation]/[module]-ivy-[revision].xml"
        artifactPattern "/filesystem/repo/[organisation]/[module]-[revision](-[classifier]).[ext]"
    }
}

Which should be a ivy repository, not ivy resolver, so I guess we are safe.

Thanks.


(Peter Niederwieser) #4

Yes, that’s fine.


(Simon Wiehe) #5

I have something like this just so I can switch off the consistency checking (some of our ivy.xml files do not properly maintain a version number), is there a suggested way to achieve this without using a custom resolver?


(Peter Niederwieser) #6

I don’t think that’s currently supported. Can’t you fix the ivy.xmls?


(Simon Wiehe) #7

Not really an option as we have hundreds of ivy.xml files that are impacted and we dont have the control over them. We would also need to fix all the historic versions. Obviously any that we publish through Gradle will be correct.


(Peter Niederwieser) #8

You could set up a proxy (e.g. Artifactory) and write a script that fixes the ivys automatically (if you can’t push the fixes upstream). Anyway, please describe your requirement as a new post of type “idea”, so that we can track it.


(Simon Wiehe) #9

I will raise a new post. Sadly I work in a large corporate environment where change is slow and ideas like setting up proxies are not viable options.


(x1000) #10

We are using a custom ivy resolver to access ivy with perforce as a backend

repositories {
    add(new com.orga.ivy.plugins.p4resolver.P4Resolver()) {...

(see https://github.com/fdrueke/ivyp4). Yes, we store everything in one repository (there’s no need to host maven or artifactory and a separate scm).

This has the benefit that sources and artifacts (3rd party libs) are severed from one instance, which is perforce. All dependencies are versioned and traceable via commit logs.

Does it mean that the proposed change will disable this ?


#11

@steveb Yes, this is an example of a custom Ivy resolver, which is deprecated. Please raise a separate forum issue so that we can track this particular use case. One of the reasons we have done early deprecation of custom Ivy resolvers is so that we understand better how they are used in the wild.


(x1000) #12

Ok, posted as http://gsfn.us/t/4ayx8


(Jens Borrmann) #13

We are currently setting local attribute to false for a FileSystemResolver referencing a network drive with very slow access rates. This allows caching for this repository.

Is there already a not deprecated way to achieve caching for file system based resolvers?

Best regards, Jens


#14

I’m not aware of a non-deprecated way to achieve this. I’ve added a story to the design doc to cover this use case. https://github.com/gradle/gradle/blob/master/design-docs/repository-transports.md#allow-caching-for-a-slow-file-backed-repository

If you’re interested in getting involved by contributing a solution, please raise this as a topic on the developer list.


Caching of slow / flapping file system repositories