Change GAV of CDI artifacts, provide relocation POMs for easier migration #913
Conversation
|
Just a few small comments, but looks good. I'll take a proper look tomorrow, but I don't expect any other finding. |
manovotn
force-pushed
the
changeGav
branch
2 times, most recently
from
d86c661 to
241ef70
Compare
| <groupId>jakarta.enterprise</groupId> | ||
| <artifactId>jakarta.enterprise.cdi-parent</artifactId> |
There was a problem hiding this comment.
These coordinates will no longer exist, no? I don't think we're relocating the parent as well (and I'm not sure if that would even work). We should use the new parent coordinates here IMHO.
There was a problem hiding this comment.
Actually, it looks like we do relocate the parent. I'm not sure if that makes sense and if that works. Did you test this?
I'm thinking it probably will work, because the relocations don't require anything from the parent, so it doesn't matter the parent is itself a relocation, but I'm not sure.
There was a problem hiding this comment.
This post https://www.lorenzobettini.it/2025/10/how-we-used-maven-relocation-for-xtend/ suggests that relocating a parent works.
It also suggests that all artifacts in one Maven Central deployment must share the group ID, which means that deploying our relocations (just like theirs) won't work and will have to be done separately.
There was a problem hiding this comment.
We do relocate the parent - I have taken this over from other projects/PRs I have seen using this approach.
That said, it is not required and we could skip that but it felt more natural to mimic the original structure.
It also suggests that all artifacts in one Maven Central deployment must share the group ID, which means that deploying our relocations (just like theirs) won't work and will have to be done separately.
Hm, so that means I cannot have the relocation parent module be built automatically and we will need to run a separate release job (or script in the current one) to release the relocations. That's annoying :-/
There was a problem hiding this comment.
Also, I really don't understand why we should relocate the parent, but I guess it's possible someone out there used it one way or another, so let's stay conservative and relocate it too.
There was a problem hiding this comment.
Theoretically, the release tweak should be as simple as re-running the same command but pointing to the relocation pom with -f relocation/pom.xml... hopefully.
But I am pretty sure the release plugin will be happy to prove me wrong :)
I suppose we could/should try to do some Alpha/Beta before we hit M2 so that we don't botch that one.
There was a problem hiding this comment.
Agree we can do an Alpha2 to figure this out.
2 participants
Fixes #908
Changes group ID of all artifacts to
jakarta.cdiand artifact IDs tojakarta.cdi-[something].Relocation modules are provided for all of the artifacts for ease of migration.
They should all have packaging
pomto avoid creating empty JARs and should be built (and hence released by the Jenkins) along with the whole project build.We will want to remove these modules as we get 5.0 out of the gate.
Their main purpose is to allow users to update their existing versions smoothly at which point they will start seeing a warning during the build informing them of the relocation.
Comments are welcome, this is the first time I am dealing with relocation modules so I might easily be wrong (although it does seem to work locally).