https://gradle.com/ logo
Join Slack
Powered by
Hello, using :outgoingVariants I can debug attribu...
# community-support
t
Hello, using :outgoingVariants I can debug attributes and artifacts provided by the configuration. Is there an option to also show dependencies for these outgoing variants?
👀 1
v
It's probably easiest and safest to just execute the 
generateMetadataFileFor...MavenPublication
task and look at the generated file.
➕ 1
t
ok thanks, I think I should create a feature request for this 😄
m
execute the 
generateMetadataFileFor...MavenPublication
task
This is exactly what I've been doing so far
I'm still unclear why we need to have a "variant" concept separate from the "publication" concept
This makes everything a bit harder to grasp. Probably there's a good reason but I can't help but think there is unnecessary abstraction here
I guess "publication" has a format (Maven, Ivy, ...) that "variant" is unaware of
v
Don't understand what you mean. The publication is what lands at the coordinates. The variants are different variants within that publication which is very useful for many use-cases. It is not independent, but a sub-category.
t
so in my case I am not even even that worried about the "maven/publication" part. It was a custom consumeable configuration that was used in a multiproject setup. the way it was published to maven was correct, but i made a mistake when it was all handled inside gradle
m
Don't understand what you mean.
I'm not sure I do either ^^ I think what I'm trying to say is there are different "variant". You can have "outgoingVariant" without even applying the "publishing" plugin.
So I find somewhat asymmetrical that 
./gradlew outgoingVariant
doesn't allow to debug the full outgoingVariant without applying the 
publishing
plugin
You have a "pure" "outgoingVariant" that is not related to publishing at all and that gets "materialized" into a metadata variant when you publish. The line isn't super clear to me
v
I think what I'm trying to say is there are different "variant". You can have "outgoingVariant" without even applying the "publishing" plugin.
Ah, no, that is not different. You can also consume variants purely within the build even if you don't publish them. So let me correct what I said. Variants are variants of the project. And the project with all its variants is then published using a publication.
m
How do you publish an "outgoingVariant" to maven/npm/whatever
It's not really made for that. So the Gradle metadata publishing format leaks into the build tool model
t
well i would say its a bit confusing that there are the concepts variants/consumeable configurations/ publications and they all very related but not quite the same. And well its might get a bit overly complicated for beginners when they just want to understand why a file is sometime not copied from on project to another
💯 1
m
Yea exactly
v
How do you publish an "outgoingVariant" to maven/npm/whatever
It's not really made for that. So the Gradle metadata publishing format leaks into the build tool model
I'm still not sure what you mean. The variants - speaking of files - are jars with classifier. And the metadata (only GMM as POM is simply not able to) knows about which variants exist and which artifact and dependency belongs to which variant. With pure POM, you would just have the classified jars and in the POM optional dependencies as POM just cannot know more by design. So yes, variants are of course made to be published, unless you configure a variant to not be published but to just be available within the build for cross-project dependencies, but not for external consumers.
m
variants are of course made to be published, unless you configure a variant to not be published but to just be available within the build for cross-project dependencies, but not for external consumers.
Exactly. The "variants" (as in 
ConfigurationVariantMapping
, etc...) exist irrespective of publishing. But all the concepts (attributes, etc...) are linked to the Gradle metadata JSON format. The Gradle build tool is now tightly couple to the Gradle metadata format
It might not be an issue at the end of the day. But it's a departure from the initial philosophy of "The Gradle build tool" is publishing agnostic.
And for the record, I understand this is hard. See also the Kotlin uklib discussion.
Finding the "good", "portable", "flexible", "efficient", etc... publication format is still an open question IMO
v
> Exactly. The "variants" (as in 
ConfigurationVariantMapping
, etc...) exist irrespective of publishing. But all the concepts (attributes, etc...) are linked to the Gradle metadata JSON format. > The Gradle build tool is now tightly couple to the Gradle metadata format Not at all, it is exactly the other way around. Variants have attributes, you use the attributes to resolve those variants, whether you publish them or not. But if you publish them, you of course also publish the attributes along, so that downstream consumers can also resolve them properly.
m
Variants have attributes
Well, maven doesn't know at all about this.
v
Yes, because Maven POM is too inable. Hence the added information in the GMM. Doesn't make anything less true what I said.
m
Yep, GMM is now the superset of every possible publication format
(hopefully 😅 )
It forces everything into the attribute model. Back to the initial point, let's embrace that and have debugging tools that display everything without even needing to apply the 
publishing
plugin.
v
Ah, now I get what you mean. You mean you need the publishing plugin to be able to generate the metadata file.
Well, that was just a first and most easy solution. Maybe there indeed is a way to display the dependencies with some task I just don't have in mind. And if not, that's probably indeed material for a feature request. 🙂
👍 1
I think currently you would need to create a resolvable non-transitive configuration that extends the configuration the outgoing variant is based on and then use the 
dependencies
task. Sounds like the 
dependencies
task should get a switch for this to do it internally. So for example
Copy code
val foo by configurations.registering {
    val myFeatureRuntimeElements by configurations.getting
    extendsFrom(myFeatureRuntimeElements)
    isTransitive = false
}
and then 
./gradlew dependencies --configuration foo
👍 1
t
ahh... transitive should be true? yes/no/maybe it depends...
v
it depends
On whether you want to see the transitive dependencies, or just the top-level ones that would also land in the POM or GMM file.
If you want to see all the dependencies that will be resolved, looking at the generated file is of course not helpful, but you would use this and have transitive set to true
t
https://github.com/gradle/gradle/issues/35676 if someone wants to add additional coments
⭐ 1
👌 1
2 Views
Open in Slack
PreviousNext
Powered by