This message was deleted.

A

Publication

"publishes" a

SoftwareComponent

. A

SoftwareComponent

is not necessarily bound to `Configuration`: it's an abstract way to define a deliverable. So you can see a

SoftwareComponent

as the model for "something built by Gradle". There are different kinds of components, based on the different ecosystems. For the typical Java/JVM world, the easiest is to use

AdhocComponentWithVariants

, which provides a convenient way to map "outgoing" `Configuration`s to variants.

I understand that but I don't really see why the need for a different concept? C/C++ could also very well use

Configurations

that would be added to a

Publication

?

Configuration

is too many things at the same time. Long term, this should go away IMO, because it's confusing. It's used for declaring dependencies, carrying artifacts, publications, representing a dependency graph, etc.

I see

the reason C/C++ has its own model is because the software component idea was explored there first

Can I already replace my outgoing configurations with SoftwareComponents ?

no. I wouldn't do that. Outgoing configurations are used everywhere, especially for integration with composite builds.

Alright, I'll keep the middleman 👍

As far as I remember, the intention was at some point to make the “Component”-Concept stronger in a way that you can use it to directly declare what a project represents to the outside - what consumable configurations are today. But there is also a lot of history of ideas that were neglected /changed. Thus right now, it is a bit confusing. I think at the moment though “Publication” is the thing that is (almost) redundant. Ideally you would only have one Publication per project and that would be “from(components[“java”])“. Without anything else. So the Java plugin could declare do that for you and then you wouldn’t have to deal with “Publication” at all yourself. (The plugin-publish-plugin is actually doing that.) The “Component” on the other hand lets you control which of your “consumable configurations” you want to publish. It’s also the base from which the Gradle Metadata (and POM) metadata is created. That’s why you should add a “consumable configuration” to the “java component” (instead of adding the artifacts to the Publication). Because then you do not only get the artifacts, but also the dependencies etc. (a full ‘Variant’). It’s a bit related to that other Thread where I just shared this example: https://github.com/jjohannes/gradle-demos/tree/main/extending-publications