Enhance relocation to work for all versions

[lprimak]

New feature, improvement proposal

Currently, relocation feature is version specific.
Can this be enhanced to use a version range, or make it work for all versions?

Use Case

MicroProfile is a POM-packaged artifact that points to other dependencies in org.eclipse.microprofile group.

[INFO] +- org.eclipse.microprofile:microprofile:pom:7.1:provided
[INFO] |  +- org.eclipse.microprofile.config:microprofile-config-api:jar:3.1:provided
[INFO] |  +- org.eclipse.microprofile.fault-tolerance:microprofile-fault-tolerance-api:jar:4.1:provided
[INFO] |  +- org.eclipse.microprofile.health:microprofile-health-api:jar:4.0.1:provided
[INFO] |  +- org.eclipse.microprofile.metrics:microprofile-metrics-api:jar:5.1.0:provided
[INFO] |  +- org.eclipse.microprofile.jwt:microprofile-jwt-auth-api:jar:2.1:provided
[INFO] |  +- org.eclipse.microprofile.openapi:microprofile-openapi-api:jar:4.1:provided
[INFO] |  +- org.eclipse.microprofile.rest.client:microprofile-rest-client-api:jar:4.0:provided
[INFO] |  \- org.eclipse.microprofile.telemetry:microprofile-telemetry-api:pom:2.1:provided

What needs to be accomplished (example) is to add a some kind of relocation so that:

• org.eclipse.microprofile:microprofile:8.0 is the last org.eclipse.microprofile:microprofile artifact published
• org.eclipse.microprofile:microprofile:8.1 (and later) is automatically redirected to jakarta.microprofile:microprofile:8.1

The end result of (for example) including of org.eclipse.microprofile:microprofile:pom:10.7:provided
would result in a tree that looks something like this:

[INFO] +- jakarta:microprofile:pom:10.7:provided
[INFO] |  +- jakarta.config:microprofile-config-api:jar:3.1:provided
[INFO] |  +- jakarta.fault-tolerance:microprofile-fault-tolerance-api:jar:4.1:provided
[INFO] |  +- jakarta.health:microprofile-health-api:jar:4.0.1:provided
[INFO] |  +- jakarta.metrics:microprofile-metrics-api:jar:5.1.0:provided
[INFO] |  +- jakarta.jwt:microprofile-jwt-auth-api:jar:2.1:provided
[INFO] |  +- jakarta.openapi:microprofile-openapi-api:jar:4.1:provided
[INFO] |  +- jakarta.rest.client:microprofile-rest-client-api:jar:4.0:provided
[INFO] |  \- jakarta.telemetry:microprofile-telemetry-api:pom:2.1:provided

Why do this?

MicroProfile wants to merge with Jakarta EE.
However, it wants to avoid the mistakes that happened with Java EE -> Jakarta EE transition.
MicroProfile wants to provide a smooth, non-breaking migration path from MicroProfile to Jakarta EE.

What are the alternatives?

Just publish both artifacts - Unfortunately this will introduce duplication and confusion, in addition to dependency clashes from transitive dependencies including both / either variants of the artifact

Why don't everybody just change / update the GAV coordinates? - There are many dependncies to these coordinates,
and changes require "waiting" for many dependencies to upgrade, which breaks the smooth upgrade path the the new artifacts.

[joakime]

The <relocation> element in the pom?

For the pom.xml, I don't see how that would work.
The pom itself is version specific, and deployed to a specific version.

There would need to be something like a maven-metadata.xml change to support that. (That's a piece of XML on the repository that sits at various levels (group, artifact, etc) to support things outside of a specific pom.xml.

[cstamas]

Maven 4 introduces new kind of relocation, essentially supporting 2 kind of relocations:

• distribution based, a la Maven 3 had (100% same)
• user provided relocation, where user provides relocation info

They both kick in very same place and have exactly same effect, the difference is that first is provided by publisher (as before), while latter by consumer.

Note: this is still "preview", so depending on this in production is not recommended yet. Or, if you do, please consider possible changes to them. Still, feedback is welcome.

See sources:
https://github.com/apache/maven/tree/master/compat/maven-resolver-provider/src/main/java/org/apache/maven/repository/internal/relocation

See documentation for user ones here:
https://github.com/apache/maven/blob/master/api/maven-api-core/src/main/java/org/apache/maven/api/Constants.java#L323-L344

[lprimak]

Maven or maven resolver can theoretically be modified to support this.

[lprimak]

Would this new maven 4 relocation support version ranges so you won't have to publish 2 GAV every time?

[cstamas]

This "new maven 4 relocation" (user provided one) does not involve any publishing. It happens on consumer side.

[cstamas]

Initial inspiration for user provided (consumer side) relocation was inspired by things like https://github.com/qos-ch/reload4j The idea is that user can relocate to a "drop in" replacements artifact in build, and consumer could perform these replacements even without touching the sources of built project.

As I said, it is "preview", so any new use case or improvement idea is welcome.

[lprimak]

I'm not sure I understand what that means :(

[lprimak]

I guess the question is will it work for a use case when any version later then micrprofile:config:5.0 could be relocated to Jakarta:EE:config:5.0 without publishing the former GAV every time.

[lprimak]

I updated the heading of the issue to demonstrate the use case better. Hope this helps

[cstamas]

So you publish 8.1 with relocation, once.

But expecting that 9.x and 10.x will relocate too assumes that consumers still use org.eclipse.microprofile:microprofile:pom:10.7 as dependency? So it assumes that consumers do edit their POM (version they consume do changes), but they don't bother with changing the G? What is the rationale here? Once redirection kick in, their build will be sparkled with WARNs anyway (about redirection) and the only way for them to get rid of warnings is to adjust: change the G in their POM to jakarta....

[lprimak]

When older transient dependencies use older GAV, you can use <dependencyManagement> to upgrade the new version.
Since some older dependencies won't upgrade GA for some time.

This allows convergence of all actual JAR APIs to the new Jakarta-based artifacts.

[cstamas]

Relocation works like this (timeline):

• publisher publishes GA:1.0
• consumer consumes GA:1.0
• (all fine here)
• publisher relocates from G to G2 (publishes POM w/ relocation info to GA:1.1, publishes new artifacts to G2A:1.1).
• consumer who did nothing just up version from 1.0 to 1.1 will still build successfully, but will get a big fat warning about relocation
• publisher publishes G2A:1.2 only (there is no GA:1.2)
• consumer going GA:1.1 to GA:1.2 will fail (no such artifact), as he did not his "homework" when he upped from 1.0 to 1.1 and Maven warned him
• (new consumers go for G2A:1.2 obviously)
• ...

[lprimak]

Yes, and I would like to enhanced so that:

consumer going GA:1.1 to GA:1.2 will fail (no such artifact), as he did not his "homework" when he upped from 1.0 to 1.1 and Maven warned him

Instead of failing, consumer going to GA:1.2 will go to G2A:1.2 automatically.

[cstamas]

When older transient depnendencies use older GAV, you can use <dependencyManagement> to upgrade the new version. Since some older dependencies won't upgrade GA for some time.

In that case just publish relocation POM (in old G) for each published artifact (in new G) too, but this raises question about the quality of those builds, as obviously we talk about builds that do warn (loud warn) users, and they just do nothing? If you assume this is acceptable, then you should provide the relocation POMs for each POM you publish to new G. Publisher relocation is up to publisher, not Maven.