Dependency substitution of modules with a classifier

Help/Discuss
1

Hi,

we have projects with dependencies to other projects that generates multiple jar files with
different classifiers. Usually the dependencies are defined by module versions. For example:

dependencies {
    compile mygroup:mylib-a:1.0.0-SNAPSHOT
    compile mygroup:mylib-b:1.0.0-SNAPSHOT
    compile mygroup:mylib-b:1.0.0-SNAPSHOT:api
}

When working on these projects we would like to replace the dependencies by project references of
a multi-project build like:

compile project (':mylib-a')
compile project (':mylib-b')
compile project (path:':mylib-b', configuration:'api')

We don’t want to change the version controlled build file every time. So the replacement is done by
dependency substitution:

configurations.all {
    resolutionStrategy.dependencySubstitution.all { DependencySubstitution dependency ->
        if (dependency.requested instanceof ModuleComponentSelector) {
            def targetProject = findProject(":${moduleName}")
            if (targetProject != null) {
                dependency.useTarget targetProject
            }
        }
    }
}

But the problem is that the ModuleComponentSelector has no attribute ‘classifier’. Is there any
other way to retrieve the classifier of a dependency substitution?

Also how can we choose a configuration with DependencySubstitution.useTarget?

Greetings
Christoph

1 Like
2

Any suggestions? Especially the second question (DepencySubstitution with configuration) is very critical for us.

2 Likes
3

Has this gone anywhere?

1 Like
4

It is important for us as well.

5

@st_oehme why is this not possible? or is it?

I’m also trying to do this:

androidTestImplementation "foo:bar:1.0:test-helpers@jar"
configurations.testImplementation.resolutionStrategy.dependencySubstitution {
	substitute(module(group: 'foo', name: 'bar, version: '1.0', classifier: 'test-helpers', ext: 'jar'))
			.with project(path: ':external:foo:bar', configuration: 'test-helpers')
}
6

It’s not possible at the moment. Selecting a specific variant for substitution definitely makes sense, it just hasn’t made it all the way up our the priority list.

Please express your support and use cases on this issue: https://github.com/gradle/gradle/issues/3880