olamy commented on PR #31: URL: https://github.com/apache/maven-install-plugin/pull/31#issuecomment-1163833952
> Let's imagine that we change package to o.a.m for resolver. It's like change like jakarta from javax. How this will look like? If we just change it, all old plugins will be broken. If we use our shared component - yes we can use reflections and our plugins may work. But what about everything else from community? > Correct I definitely like your comparison here `javax. to jakarta` But except you missed to add then the next step will back to javax (well maybe javax.foo) Because this will be case to change again to org.apache.maven once maven-resolver has been migrated. The problem here is to have to switch to a package we know it will be removed because it's `org.eclipse.` package coming from a Apache source repo and deployed under the groupId `org.apache.maven` The big mess is here, so the goal is to move away from this package because it simply doesn’t belong here. Imagine if someone told you: we will remove javax. to javax.foo and in the middle for a bit of time there will be jakarta. sounds like a waste of time? > +1 here to PR - this simplify code and remove access to API via reflections Why not removing all of this from m-artifact-transfer so downstream consumers will not pull old dependencies. > > and maybe let's start discussion how to rename package on mailing list. This will tak years no we have a big opportunity with maven 4.x -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
