Question about multi-project releases and group-IDs

The Eclipse Dataspaceconnector project is currently undergoing a rebranding process, in the course of which we will also adapt the groupId for all our projects. While discussing the technical ramifications of that in a technical working group we came across some questions, and I wonder whether you could help out in resolving them.

As you may know we have our "core" project, plus a few dependent projects ("components") that depend on the "core" project via maven/gradle dependencies. For publishing to Nexus (snapshots + staging for release) we use the Gradle Nexus Plugin.

The only thing that is pretty much set in stone is that we want all our various components/projects to have the same version number to avoid headaches with transitive dependencies and maintaining compatibility matrices. We would prefer having a separate build (=Jenkins Job) for every project, if possible.

According to a question I raised in the Nexus Plugin repo, it sounds like that is not really possible, because opening and closing the staging repo needs to be done in the same gradle invocation, or at least in the same Jenkins runner, in subsequent shell commands. Furthermore, my suspicion is that one cannot "add" artifacts to an already published version, is that correct?

Which would mean the following sequence is not possible:

• job 1: builds core:0.0.1, publishes it to maven central
• job 2: builds projectA:0.0.1 (which depends on core:0.0.1) and publishes it to maven central
• job 3: builds projectB:0.0.1 (which depends on core:0.0.1 and projectA:0.0.1), and publishes it to maven central

Question 1: is the above statement correct?

If so, we were discussing whether having sub-groups could be a solution. Essentially what we would try to do then is create a sub-group-id per project, for example:

• org.eclipse.edc.connector
• org.eclipse.edc.projectA
• org.eclipse.edc.projectB
• etc.

and we would have one Jenkins build/publish job per sub-group.

Question 2 then is, whether EF supports subgroups at all, and whether we can publish different projects with separate subgroups to MavenCentral? And on a general note I wanted to ask if you had any information about how other multi-repo projects approach this situation? What would you recommend as being the best approach here?

Happy to answer any questions you may have.

Thanks a ton in advance!

CC'ing @mspiekermann

added IT-prioritylow IT-severitylow ~31169 team:releng labels

Are you planning to have different groupIDs for the different projects, or just different artifactIDs?

I assume you are planning to do something like

• groupId: org.eclipse.edc, artifactId: core
• groupId: org.eclipse.edc, artifactId: foo
• groupId: org.eclipse.edc, artifactId: bar

Then you can release those projects separately.

assigned to @fgurr

@fgurr different artifact ids will come naturally i think, so we can assume that they are unique across all projects. The decision whether we will use different group ids or not will be influenced by whether either one is technically possible, and if there are limitations or advantages. Meaning: if we use the same group id everywhere, can we have staggered builds? if we use different group ids, do we need permission for every subgroup-id or is that "implicit"?

Meaning: if we use the same group id everywhere, can we have staggered builds?

Yes

if we use different group ids, do we need permission for every subgroup-id or is that "implicit"?

You will need permission.

Staggered builds - Yes

that means we can "add" artifacts to an already-published version? For example in a first run we publish org.eclipse.edc:core:0.0.1 and then, in a second job, we publish org.eclipse.edc:projectA:0.0.1?

that means we can "add" artifacts to an already-published version?

There might be some ambiguity or misunderstanding. In Maven-land you can only update Snapshot versions. You can't update release versions. So once org.eclipse.edc:core:0.0.1 is released, you can never update that version, you can only release a new version org.eclipse.edc:core:0.0.2.

That does not stop you from releasing another artifact like org.eclipse.edc:projectA:0.0.1 though, since it's a different GAV (groupId, artifactId, version).

For example in a first run we publish org.eclipse.edc:core:0.0.1 and then, in a second job, we publish org.eclipse.edc:projectA:0.0.1?

Yes

ok, i was aware of the non-replaceability of released versions in Maven. I think you answered all the questions I had for the moment. As always, thanks a lot for the timely responses.

I will take the information back to my fellow maintainers. I'll close this issue and in case we decide to go with separate group IDs, i'll open another issue to request permissions for those.

I will take the information back to my fellow maintainers. I'll close this issue and in case we decide to go with separate group IDs, i'll open another issue to request permissions for those.

I'd recommend to use the same groupId. This will also improve visibility at Maven Central, since the different artifacts are grouped by their groupId.

closed

mentioned in issue #2133 (closed)