[2.x] Undo GAV changes

[cstamas]

The top level G is org.apache.maven.executor and everything except for maven-executor-plugin is there.

At the same time update parent POM to 48.

Wanted layout is:

[hboutemy]

such parent POM artifactId will publish executor-${version}-source-release.zip to svn dist
objective of previous trick is to get maven-executor-${version}-source-release.zip to svn dist

"executor" is not really a name that is very Maven specific

[hboutemy]

how is that change related to "undo GAV change"?

[hboutemy]

not related to "Undo GAV change"

[cstamas]

Yes, upped parent too (hence reformat as well,due spotless changes)

[hboutemy]

"upped parent" = "undo GAV change"?
I know it's 1 line, but not the same intent, definitively

[cstamas]

such parent POM artifactId will publish executor-${version}-source-release.zip to svn dist objective of previous trick is to get maven-executor-${version}-source-release.zip to svn dist

"executor" is not really a name that is very Maven specific

But is very same as enforcer does:
https://dist.apache.org/repos/dist/release/maven/enforcer/

[cstamas]

Also, org.apache.maven G is getting crowded, so I would leave that purely to core artifacts as today.

Maybe we need some changes then to our source bundle creation?

[hboutemy]

But is very same as enforcer does:
https://dist.apache.org/repos/dist/release/maven/enforcer/

true, but my personal opinion is that "enforcer" is less vague than "executor", and I can't change the past, just trying to have clear future

Maybe we need some changes then to our source bundle creation?

the question is just about the file name being based on artifactId: whatever bundle creation approach you take, you'll have the same

[hboutemy]

Also, org.apache.maven G is getting crowded, so I would leave that purely to core artifacts as today.

org.apache.maven:maven-executor already exists: https://repo.maven.apache.org/maven2/org/apache/maven/maven-executor/

too late to avoid it

[cstamas]

org.apache.maven:maven-executor already exists: https://repo.maven.apache.org/maven2/org/apache/maven/maven-executor/

too late to avoid it

Yes, as this project was part of maven 4 project, and maven-executor was (is currently) part of Maven 4 core artifacts. Once this is released, will replace it, and org.apache.maven:maven-executor artifact will cease to exist (will be replaced by this one).

[hboutemy]

org.apache.maven:maven-executor artifact will cease to exist

past releases won't cease to exist in Maven Central: I really don't see what you want to avoid by not continuing to use the existing coordinate in Maven Central

[cstamas]

Simple: I don't want to distinct projects produce same GAs. That is wrong thing to do and exactly due non-removal policy, is way for more trouble

[gnodet]

What about a middle ground: keep the groupId change to org.apache.maven.executor but use maven-executor as the parent artifactId instead of executor?

<groupId>org.apache.maven.executor</groupId>
<artifactId>maven-executor</artifactId>

This would:

• Move the parent out of org.apache.maven, avoiding the GA collision with the old core artifact (org.apache.maven:maven-executor vs org.apache.maven.executor:maven-executor — different groupId, so no conflict)
• Keep the source-release zip as maven-executor-${version}-source-release.zip, clearly identifiable as a Maven project
• Be consistent with the children, which already use org.apache.maven.executor as their groupId

Claude Code on behalf of Guillaume Nodet

[cstamas]

Q1: any proposal then, how to name the maven-executor module in existing repo, given that this should be the parent now?
Q2: this will go against the "common practice" of G1.G2.G3:G3 naming schema (ie. org.apache.maven:maven) of reactors
Q3: (the only identified problem so far) Do we really think that maven-executor-${version}-source-release.zip is a must, to identify a release within Maven project? As IMO by this logic, everything in this project should be "maven-this" and "maven-that", while the project umbrella off all these files and artifacts is "ASF Maven"? Isn't this redundant? We are not talking about "I found a file on my SSD and have no idea where it belongs (as file name is not fully self-contained)", but about source bundle of a ASF Maven subproject, that we all know, and SVN structure clearly shows where it belongs.

[gnodet]

I see two ways forward:

Solution 1 — -parent suffix on the current name

Keep the project name as-is, but use maven-executor-parent as the parent artifactId:

<groupId>org.apache.maven.executor</groupId>
<artifactId>maven-executor-parent</artifactId>

• No GA collision with the child maven-executor module
• Source-release zip is maven-executor-parent-${version}-source-release.zip — clearly Maven-identifiable
• -parent suffix is a well-established pattern (org.apache.maven:maven-parent itself uses it)

Solution 2 — Rename the project to something less vague

If the real issue is that "executor" on its own is too generic, we could rename the project. That would let the G:G3 convention work with a self-descriptive name. Three candidates:

Project name	Parent GAV	Source-release zip
maven-build-executor	o.a.m.buildexecutor:build-executor	build-executor-${version}-source-release.zip
maven-runner	o.a.m.runner:runner	runner-${version}-source-release.zip
maven-launcher	o.a.m.launcher:launcher	launcher-${version}-source-release.zip

maven-build-executor is the lightest touch — keeps "executor" but qualifies what's being executed, removing the java.util.concurrent.Executor ambiguity.

Claude Code on behalf of Guillaume Nodet

[gnodet]

Fwiw, I'm also fine with using org.apache.maven:maven-executor for the child artifact, provided that the version is > latest one, i.e. it should be 5.0.0. With the current state, we're going back, so that's very confusing.