How to intercept [organization] and [module] in ivy repository patterns?


(Baiyan Huang) #1

For example, my ivy repository is like:

ivy {
        url "$NetworkDir"
        layout 'pattern', {
            artifact "[organisation]/[revision]/lib/[module]/[artifact].[ext]"
        }
}

Here, the organization and module might be of multi-level, like: 1. organization: division.package 2. module: project.subproj (could be of any level)

And I want the pattern resolve to (replace . with /, and add some other directory in between): > $NetworkDir/division/EXTRADIR/package/lib/project/subproj/artifact_name.jar

The reason I want to do this is because above is the firm infrastructure standard which could not be changed shortly.

Is there any way to hook into [organization] and [module] by changing its value before it resolve to the right artifact?

Thanks very much.

(Use FileSystemResolver we could override findArtifactRef, but it is going to be deprecated, we will need a alternative)


(Luke Daley) #2

Unfortunately there’s no way to do this.


(Baiyan Huang) #3

Thanks Luke,

We currently using gradle’s FileSystemResolver, and there is a way for us to intercept such information by overriding

@Override
protected ResolvedResource findArtifactRef(Artifact artifact, Date date)

and manipulate ModuleRevisionId, like:

@Override
protected ResolvedResource findArtifactRef(Artifact artifact, Date date) {
        ModuleRevisionId mrid = artifact.getModuleRevisionId();
         mrid = ModuleRevisionId.newInstance(intercept(mrid.getOrganisation()),intercept(mrid.getName()), mrid.getBranch(), mrid.getRevision(),mrid.getQualifiedExtraAttributes())
    return findResourceUsingPatterns(mrid, artifactPatterns, artifact, getDefaultRMDParser(artifact.getModuleRevisionId().getModuleId()), date);
}

Our organizaiton heavily relies on this behavior, if gradle 2.0 is going to deprecate FileSystemResolver, but without a hook to do the same thing, I am afraid this would be a regression


(Luke Daley) #4

The general use case here of a more complex derived mapping is something that we plan to support natively by the concept of repository layouts. In short, by the time we remove Ivy resolver support you’ll be able to do this with Gradle’s native resolvers.


(Baiyan Huang) #5

Cool, thanks Luke!


(Baiyan Huang) #6

Hi, Luke - hence gradle 2.0 is coming out soon, I would like to know how to achieve this without FileSystemResolver, this is very critical to our firm, as all of our projects are depending on this, if gradle 2.0 don’t have a alternative, but deprecate FileSystemResolver, then we are pretty much stuck here.

Thanks very much.