Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow dependency resolve rule to influence variant selection #1340

Open
bmuschko opened this issue Feb 7, 2017 · 7 comments
Open

Allow dependency resolve rule to influence variant selection #1340

bmuschko opened this issue Feb 7, 2017 · 7 comments

Comments

@bmuschko
Copy link
Contributor

@bmuschko bmuschko commented Feb 7, 2017

Original issue: https://issues.gradle.org/browse/GRADLE-2763

Expected Behavior

A dependency resolve rule can set or change the classifier attribute or a requested module.

For example:

configurations.all {
     resolutionStrategy.eachDependency { DependencyResolveDetails details ->
         def req = details.requested
         if(req.group == 'org.codehaus.groovy') {
             details.useTarget group: req.group, name: req.name, version: req.version, classifier: 'indy'
         }
    }
}

Current Behavior

Only the attributes group, name and version can be set/changed.

Context

Enforcing a module with a specific classifier.

@socketbind

This comment has been minimized.

Copy link

@socketbind socketbind commented Jun 6, 2017

Hi bmuschko,

This would be particularly great when somebody needs to replace dependencies with their obfuscated counterparts which are usually published with the "obfuscated" classifier.

@jhansche

This comment has been minimized.

Copy link

@jhansche jhansche commented Oct 16, 2017

Should also support ext as well. I.e., to switch between zip vs jar vs aar, etc, packaging.

@bigdaz bigdaz changed the title Dependency resolve rule can set/change classifier attribute Allow dependency resolve rule to modify classifier attribute Nov 12, 2017
@kazvictor

This comment has been minimized.

Copy link

@kazvictor kazvictor commented May 23, 2018

I ran into this for the ext property. Here is a link to a stackoverflow question that details the use case:
https://stackoverflow.com/questions/50477558/changing-default-gradle-dependency-file-extension

@fodil-a

This comment has been minimized.

Copy link

@fodil-a fodil-a commented Aug 17, 2018

Hi,
any update ?
I have the same issue.

@paplorinc

This comment has been minimized.

Copy link
Member

@paplorinc paplorinc commented Aug 23, 2019

@ljacomet, @jjohannes, @melix, this would be useful for e.g. using the no_aop variant of Guice, i.e. useTarget group: requested.group, name: requested.name, version: "4.2.2", classifier: 'no_aop' in GE.
Is there another way of doing this?

@ljacomet

This comment has been minimized.

Copy link
Member

@ljacomet ljacomet commented Oct 11, 2019

Dependency management in Gradle has now established the use of variants as a better solution to this problem.
Nonetheless, the problem remains as it is not possible to select a specific variant with this API.

Updating the title to reflect the direction of a possible fix.

@ljacomet ljacomet changed the title Allow dependency resolve rule to modify classifier attribute Allow dependency resolve rule to influence variant selection Oct 11, 2019
@jjohannes

This comment has been minimized.

Copy link
Member

@jjohannes jjohannes commented Oct 11, 2019

I am not sure if we want to add more variant awareness to resolve rules. I think the use cases should rather be solved without resolve rules if possible. So if we need to do something at all here, I would currently tend to do what was originally requested (if it is easy to do).

But to concretely answer @paplorinc question and offer alternative solutions:
With Gradle 6, you can solve this with feature variants and capabilities. Since Guice does not publish these variants (yet, maybe they will in the future :)), you can use component metadata rules to add the missing information.
This is actually a sample in the new docs: https://docs.gradle.org/release-nightly/userguide/component_metadata_rules.html#making_different_flavors_of_a_library_available_through_capabilities
(I just saw that the second part of the example is wrong there, should be this)

In the case described in this issue, where a transitive dependency already brought in the other variant of guice, you'll probably end up with a conflict. This can then be resolved like this:

configurations.all {
    resolutionStrategy.capabilitiesResolution.withCapability("com.google.inject:guice") {
        select(candidates.first { !it.variantName.contains("noAop") })
    }
}

Or you add another metadata rule 'correcting' the dependencies in the metadata of whatever brought in the 'wrong' variant.

Note you need Gradle 6 (RC will be available shortly) for this.

@ljacomet ljacomet added the @jvm label Feb 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.