https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# dependency-management
s
This message was deleted.
v
Did you try to use 
dependencyInsight
or a build 
--scan
? Both should at least display which variant with which attributes were resolved. Can you maybe knit an MCVE, so that it is clear what we are talking about in detail?
c
I’ll see if I can reproduce it in a reasonable way. I know there we changes recently around infering the existence of maven source jars… I was wondering if that might have an effect here.
nm… pretty sure this is my bad… failing to propagate capabilities in one spot
👌 1
In this build: https://gist.github.com/chrisdennis/dae044fb31265ec59fa38f49138b5b60 Shouldn’t the artifactView be using the required capability to pick the “right” sources artifacts? Instead it can’t pick between the two variant sources artifacts:
Copy code
> Could not resolve all files for configuration ':runtimeClasspath'.
   > The consumer was configured to find sources. However we cannot choose between the following variants of org.ehcache.modules:ehcache-xml:3.10.8:
       - org.ehcache.modules:ehcache-xml:3.10.8 variant sourcesElements declares sources:
           - Unmatched attributes:
               - Provides attribute 'artifactType' with value 'jar' but the consumer didn't ask for it
               - Provides its dependencies declared externally but the consumer didn't ask for it
               - Provides its elements packaged as a jar but the consumer didn't ask for it
               - Provides release status but the consumer didn't ask for it
               - Provides runtime but the consumer didn't ask for it
       - org.ehcache.modules:ehcache-xml:3.10.8 variant jakartaSourcesElements declares sources:
           - Unmatched attributes:
               - Provides attribute 'artifactType' with value 'jar' but the consumer didn't ask for it
               - Provides its dependencies declared externally but the consumer didn't ask for it
               - Provides its elements packaged as a jar but the consumer didn't ask for it
               - Provides release status but the consumer didn't ask for it
               - Provides runtime but the consumer didn't ask for it
(fixed my original issue by adopting artifactViews)
I’ve worked round this by duplicating the runtimeClasspath resolve results in to a new bucket configuration and resolving a fresh configuration that targets sources variants. Would be nice to be able to use an artifactView here though.
v
Yeah, it seems you need to do it like
Copy code
configurations.create("sourceFiles") {
    extendsFrom(configurations.runtimeClasspath.get())
    attributes {
        attribute(Category.CATEGORY_ATTRIBUTE, objects.named<Category>(Category.DOCUMENTATION))
        attribute(DocsType.DOCS_TYPE_ATTRIBUTE, objects.named<DocsType>(DocsType.SOURCES))
    }
}.incoming.artifactView {
}.files.forEach {
    println("Source File: $it")
}
You also have an aftifact view there. 😄 I guess the relevant point is the JavaDoc of 
withVariantReselection()
which says
When invoked, this view will disregard existing attributes of its parent configuration and re-resolve the artifacts using only the attributes in the view's attribute container.
I'm not sure though, whether it is intended, that also the attributes on the dependencies are discarded. I personally would say that this might not be intended and would recommend reporting it as bug. But my (and obviously your) expectations could of course also be wrong.
c
yeah… I tried debugging the code to see if the behavior seemed intentional… but I got lost in a rats nest.
I should stop writing plugins that do crazy things
v
Not if you find Gradle bugs on your way 🙂
Open in Slack
PreviousNext
Powered by