Custom ivy resolver deprecation in gradle 2.x?

Old Forum
1

Hi, All,

I’ve heard from this StackOverflow question (gradle - Custom Ivy resolver documentation - Stack Overflow) 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:

  • Is custom ivy resolvers specifically means the ivy methods provided in RepositoryHandler(RepositoryHandler - Gradle DSL Version 8.4 * Would this feature be deprecated on gradle 2.0? * If yes, what would be alternatives, if I need to resolve artifacts from a non-standard repository? we are still using ivy.xml for dependencies.

Thanks very much!

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.

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.

4

Yes, that’s fine.

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?

6

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

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.

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.

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.

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.

12

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

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.

1 Like