module1:
configuration1Module1
attribute1
dependency moudule2
configuration2Module1
attribute2
dependency moudule2
configuration3Module1 // Need this configuration provide both artifact1 and artifact2
attribute3
extendsFrom configuration1Module1
extendsFrom configuration2Module1
module2:
configuration1Module2
attribute1
artifact1
configuration2Module2
attribute2
artifact2
I need to make configuration3Module1 configuration to get all artifacts including transitive from both configurations configuration1Module1 and configuration2Module1.
But extendsFrom just ‘inlined’ all dependencies to configuration3Module1 and resolution happens from configuration3Module1 that have attribute3 and fail with resolving it.
How to make this behave as when resolving configuration3Module1 first resolve all extendsFrom configurations by their attributes and all resulted dependencies gather in configuration3Module1?
As you have seen, attributes defined on configurations are not inherited, only the dependencies.
If you have attributes declared directly on a dependency, then this would be carried over.
But not the ones declared on a configuration.
Could not resolve all task dependencies for configuration ':module2:allVariants'.
> Could not resolve project :module1.
Required by:
project :module2
> Module 'org.example:module1' has been rejected:
Cannot select module with conflict on capability 'org.example:module1:1.0-SNAPSHOT' also provided by [org.example:module1:1.0-SNAPSHOT(variant1), org.example:module1:1.0-SNAPSHOT(variant2)]
> Could not resolve project :module1.
Required by:
project :module2
> Module 'org.example:module1' has been rejected:
Cannot select module with conflict on capability 'org.example:module1:1.0-SNAPSHOT' also provided by [org.example:module1:1.0-SNAPSHOT(variant1), org.example:module1:1.0-SNAPSHOT(variant2)]
That’s not at all the same result you described initially.
As the error message tells you. The two variants have the same capability, which expresses that they are mutually exclusive, so you can’t depend on both in one configuration.
I don’t know if your example is now just too downstripped and thus different. But in the MCVE you could also just omit the attributes and say “give me configuration variant1” and “give me configuration variant2”.
Or you could have in the consumer two configurations and from then both in the jar task, but then you of course do not get conflict resolution.
And you should most probably better not use an attribute with name string, that’s a tiny bit generic.
While minimizing to MCVE and following your advise to declare attributes on dependency i came to this code.
Initialy those 2 dependencies were in different configurations and transitevily through extendsFrom got into main configuration but without needed attributes.
I wanted to avoid passing several configurations to task such as Jar, Shadow, etc. So i came with this question.
As i now understand that it is not possible to keep 2 same dependencies with different attributes in the same configuration, i’ll refactor my code to pass several configurations.
Thanks for help!