Cannot target a project variant with dependency substitution

[bigdaz]

It is possible to target a particular project configuration in a dependency declaration (project(path: ':groovy', configuration: 'indy')), but this isn't possibly inside a dependencySubstitution block. This is a much requested feature and blocks many users from using dependency substitution. I'm confident it will become much more requested as people start to use composite builds.

The use of project configurations is problematic, since a configuration can be used to model different variants of the same component (fat jar, classes directory, etc) and can also be used to model a multiple different components within the same project (library, test-fixtures, etc). These should be treated differently from a dependency resolution standpoint, but this difference is lost when modelled as a configuration.

We have a couple options:

• First add the ability to target project configurations via dependency substitution, making this equivalent to the project dependency declaration. Later we could add more features to replace the use of configuration with better modelling of variants and components, and promote the use of these improved concepts.
• Push hard to add the modelling of variants and components now, so that adding target configuration to dependency substitution isn't strictly required.

Either way, we should address this as fairly major limitation to composite builds as they stand.

[Loffe]

Any update on this issue? Is it being planned, or do you want help from the community?
It is currently blocking us from using dependency substitution.

https://groups.google.com/forum/#!searchin/gradle-dev/dependency$20substitution$20with$20project$20configuration|sort:date/gradle-dev/CuzXSQ7gyUQ/WW3ICQe4HgAJ
https://groups.google.com/forum/#!searchin/gradle-dev/dependency$20substitution$20with$20project$20configuration|sort:date/gradle-dev/RhJosy_rlhU/hgSh7blOAQAJ

[bigdaz]

We are working hard on this:

Push hard to add the modelling of variants and components now, so that adding target configuration to dependency substitution isn't strictly required.

However there's quite a long road between the current work and solving the common composite-builds use case.

In the end we want to be able to:

1. Define multiple component outputs for a project, and give them different identities. This could be something as simple as allowing a build to declare a SoftwareComponent based on a Configuration instance, and add this to project.components
2. Allow a project selector to target a particular component output for a project.
3. Allow dependency substitution to replace a module selector with a project selector that targets a particular component output.

If you're interested in helping out, you might want to start by exploring SoftwareComponent and related types. Note that this is definitely a work-in-progress.

[little-fish]

Hello.
Any updates here?

[JamesXNelson]

This is something I am interested in helping out on. I've looked at SoftwareComponent (a few times) but was not really able to understand just what would be required to make a new instance that works sanely (w.r.t. publishing and consuming different variants of a given project).

I'm building a set of tools for publishing sets of archives (jar, sourceJar, api, spi, etc) for multiple platforms (main, gwt, j2cl, android, etc) from sets of projects using multiple sourcesets. I have a pretty good grip on getting these sourcesets wired up to behave within a build, but once composite are in play, things get ...unhappy.

While I have the interests of my own use case at heart, I'd be happy to inherit some scope to build TheRightThing as a path to getting what I need... especially if there was a checklist of ThingsThatShouldBeDone and ThingsThatMustNotBeDone to guide me (or any other pointers to consider when tackling this).

For example: would this hurt less if I was publishing to an ivy repo?
is it better to create multiple publications, or to add artifacts to a single publication?

Sorry, I know this isn't something you can't just frivolously answer; I look forward to being a productive guinea pig :-) If there was some documentation / recommended reading regarding variants, and associated best practices, I'd love to read it :-)

[ljacomet]

Now that variant aware selection is established as the Gradle reference for such problems, renaming this to indicate that it is not possible to select the specific variant of a project or dependency through substitution rules.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.