From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

ok, I got a hint with: `outgoingVariants` task

Still think I would enjoy having some documentation about attributes (not saying it doesn't exist, just didn't found it)

<https://docs.gradle.org/current/userguide/variant_model.html> :tada:

But I see in artifacts only shows the project jar, while it should have all the runtime dependencies, I guess dependencies are not resolved in that task

Fwiw, did you see <https://docs.gradle.org/current/userguide/cross_project_publications.html> ?

If you mean with "in artifacts" in the output of `outgoingVariants`, then yes, it only shows the artifacts as the name suggests, not the dependencies.

And yes, if you select the same consumable configuration using the attributes it should result in the same result, yes. You can even set the attributes on the dependency individually if you don't want those attributes for all dependencies in that `someClasspath` configuration.

<@UDC9Q9RD0> is where I started, but I think I missed some details

And regarding the attributes, each ecosystem or plugin should describe the attributes defined.
Here you find the built-in attributes: <https://docs.gradle.org/current/userguide/variant_attributes.html#sec:standard_attributes>

The Kotlin one should then be documented by the Kotlin plugin documentation.

And you can always check using `outgoingVariants` which are actually present.

<@URQ797WRW> I expected apiElements and runtimeElements to show different artifacts in the outgoingVariants report, that's what confused me even more

and about:
&gt; What would be the best solution?
I guess attributes has the advantage that if we use for example Kotlin multiplatform and they have another name for the configuration it won't matter..we only require a configuration with those attributes.

Small advantage I guess (over using a hardcoded configuration name)

&gt; <@URQ797WRW> I expected apiElements and runtimeElements to show different artifacts in the outgoingVariants report, that's what confused me even more
Why would you expect different artifacts?
They should be the same artifacts, but have different dependencies.
That's the result of `api` vs. `implementation` vs. `runtimeOnly`.

&gt; Small advantage I guess (over using a hardcoded configuration name)
Well, using configuration name is the old way, using attributes is the new way.
Using configuration name also only works for inter-project dependencies within one build, attributes work also with published libraries (for published variants only of course).

Dependencies get transformed into artifacts for the consumer

If that was regarding my statements about artifacts above, sure.
But that's a consumer-side thing.
`outgoingVariants` is a producer-side thing.
And from the producer PoV he has one artifact and X dependencies on that variant. :slightly_smiling_face:

I didn't think on that. I think I connected all the dots now. Thanks!