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

Old Forum Archive
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)

2

Unfortunately there’s no way to do this.

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

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.

5

Cool, thanks Luke!

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.