Changing maven groupId requires change in m2e-core

[rakus]

I tested the current state of the code with Eclipse 2021-12. It failed.
Reason is that m2e-core is explicitely checking for the groupId and artifactId of plexus-build-api.
To make this work with Eclipse a change in m2e-core is needed.

See: https://github.com/eclipse-m2e/m2e-core/blob/69dc9cf73bf03ebd082937b90d17032c9007dd15/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/embedder/EclipseClassRealmManagerDelegate.java#L82

[slachiewicz]

its' due to 9c2e013 @olamy

[olamy]

sorry but people here do not have karma to deploy to org.sonatype.plexus it's a company owned namespace.
sadly it was a bad choice of groupId from the start.
But if we (e.g codehaus-plexus folks) want to deploy new version we will need to use this new groupId.

[laeubi]

@olamy please let us know (at m2e) what new GAV should be supported, I'll take care fir a fix then!

[laeubi]

Is this new item already deployed on central? Would you accept a PR that implements a possibly bridge between old and new API?

[olamy]

this will be

  <groupId>org.codehaus.plexus</groupId>
  <artifactId>plexus-build-api</artifactId>

but no release yet

[laeubi]

but no release yet

Any plans for a release yet? Anything left to do before?

[olamy]

@laeubi can you test with this PT #37?
if it works fine I can push a release with the new groupId

[laeubi]

Is there a snapshot repo to be used? Its a bit tricky to test unreleased artifacts (as we actually need to pull them somehow into our build) but I can give it a try. Just wondering if an integration-test for the API would not be more sufficient (maybe using PlexusTestcCase?) ... I fear we will only know for sure after its released, m2e has made a new release and some people actually start using the new API :-\

[olamy]

@laeubi you can use this staging repo https://oss.sonatype.org/content/repositories/plexus-1215/.
if it works fine for you I will push the release to central

[slachiewicz]

Why we still have sonatype in package name?

[olamy]

Why we still have sonatype in package name?

because of this search result https://github.com/search?q=org%3Aapache+import+org.sonatype.plexus.build.incremental&type=code

:(

maybe we could have something such (pseudo code):
interface org.codehaus.plexus.build.incremental.BuildContext
and
interface org.sonatype.plexus.build.incremental.BuildContext extends org.codehaus.plexus.build.incremental.BuildContext
and mark org.sonatype.plexus.build.incremental.BuildContext as deprecated

[laeubi]

@olamy I think it would only be a matter of organize the imports in the IDE if the package name is changed, the only one where one needs adaption is implementors of the BuildContext and I could think of two ways:

1. We leave it to the implementor if they want to handle backward compatibility
2. one might add the old code (with deprecated annotations) and adjust the old Default impl to fetch the new BuildContext and delegate all calls to them (thats something I would have planed for m2e just in case 1. would have been choosen).

[olamy]

I don't mind changing the package.
BUT what I want to be sure is: are you guys from m2e will manage both packages and get everything still working until maven plugins change to new package?

[olamy]

FYI I have deleted the staged repo.

[olamy]

package change PR #43

[laeubi]

I don't mind changing the package. BUT what I want to be sure is: are you guys from m2e will manage both packages and get everything still working until maven plugins change to new package?

Yes, m2e can simply implement the old interface as well (if it is in an own package).

FYI I have deleted the staged repo.

All right it might be a good idea to even clean up the code a bit and simply release a 1.0.0 version I created some PRs... that way one only needs one "compat" layer?

[kwin]

FTR: The upstream change is tracked in eclipse-m2e/m2e-core#944.