Very roughly my suggestion is create new artifacts that do what you want with completely new packages. Class names can stay the same but package names must change when the artifact ID or group ID changes.
If you want to keep the fully package qualified class names the same, then don't change the artifact IDs or class locations and live with the current situation. Also important in Java 9+ is that all classes from a single package belong to a single jar./Maven artifact. E.g. do not put one class from org.apache.maven.api.xml in one artifact and other classes from that package in a different artifact. If you're already doing all that, great. However https://github.com/apache/maven/pull/975 looks to me like it's renaming an artifact without renaming any packages. That's a red flag. It might be OK if org.apache.maven:plexus-utils has never been published. Looks like it's only been published in alpha, so maybe OK? On Tue, Jan 31, 2023 at 7:47 AM Guillaume Nodet <[email protected]> wrote: > > Maybe I'm wrong, but I think you missed the point. > > We have new packages / new artifacts, mainly the xml api located in > the maven-api-xml artifact [1] with a single interface XmlNode [2]. > The implementation is in the maven-xml-impl [3] artifact. > As I said, I'd like to keep it where it is. > > Now, in order to get some compatibility with all the 3.x world in maven 4 > and achieve the goals (one of them was to have an immutable api), the > old classes which were part of the maven 3 api were slightly modified > to wrap the new ones. So we have the Xpp3Node from plexus-utils which > now wrap the XmlNodeImpl (implementing the new XmlNode interface > which is immutable). So far so good. > > However, to achieve this, I had to put those modified classes (Xpp3Node > and the related Xpp3DomBuilder) inside the maven-plexus-utils artifact [4] > (which is currently named plexus-utils, but lives inside maven. So now, > maven has a repackaged version of plexus-utils with a few modifications > that need to be maintained somewhere. We're actually > breaking https://jlbp.dev/JLBP-5, and we're trying to find a way out. > > Any better advice than keeping the current state ? > > Guillaume > > [1] https://github.com/apache/maven/tree/master/api/maven-api-xml > [2] > https://github.com/apache/maven/blob/master/api/maven-api-xml/src/main/java/org/apache/maven/api/xml/XmlNode.java > [3] https://github.com/apache/maven/tree/master/maven-xml-impl > [4] https://github.com/apache/maven/tree/master/plexus-utils > > Le mar. 31 janv. 2023 à 13:28, Elliotte Rusty Harold <[email protected]> a > écrit : > > > Thanks for the PR. That makes this clearer. I'm now -1 (-10?) on this > > entire proposal. Renaming artifact IDs without renaming packages is a > > recipe for hard to debug, hard to fix problems. > > > > See https://jlbp.dev/JLBP-6 for detailed explanation and suggestions > > > > To proceed what's needed is a hard fork of everything with new package > > names and artifact IDs. > > > > On Mon, Jan 30, 2023 at 7:31 PM Hervé Boutemy <[email protected]> > > wrote: > > > > > > Le lundi 30 janvier 2023, 14:06:28 CET Guillaume Nodet a écrit : > > > > Given this is > > > > > > > > Le lun. 30 janv. 2023 à 07:53, Hervé Boutemy <[email protected]> a > > > > > > > > écrit : > > > > > I think that first steps are: > > > > > > > > > > 1. release maven-api-meta as a shared component, given it has no > > > > > dependency > > > > > > > > > > > > https://maven.apache.org/ref/4.0.0-alpha-4/api/maven-api-meta/dependencies > > > > > .html Eventually renaming it maven-api-annotations, given it's the > > Java > > > > > package name inside > > > > > > > > > > 2. release maven-api-xml as a shared component, given it only > > depends on > > > > > previous one > > > > > > > > > > > > https://maven.apache.org/ref/4.0.0-alpha-4/api/maven-api-xml/dependencies. > > > > > html > > > > I really think having the full API in a single tree / release cycle is > > a > > > > good thing, so I'm not really keen on such a move. > > > > I don't care so much about the plexus classes which are not supposed > > to be > > > > part of the new API, so those can be moved wherever it's easier, but > > unless > > > > there's a very strong requirement, I'd really prefer to keep all the > > api > > > > packages colocated and not splitted. > > > maven-xml-impl depends on maven-api-xml which depends on maven-api- > > > meta(annotations) > > > if you want maven-plexus-utils to include maven-xml-impl but without > > having to > > > do the repackaging inside Maven core build, I don't see how you expect > > to do > > > > > > or I misunderstood the intent > > > > > > > > > > > Guillaume > > > > > > > > > then we'll refine the plan on Maven XML reimplementation of Plexus > > Utils > > > > > XML classes and injection into Maven 4 distribution > > > > > > > > > > > > > > > Creating new Git repositories for > > > > > 1. maven-api-annotations > > > > > 2. and maven-api-xml > > > > > is easy, but it can't be deleted later: I need clear consensus on the > > > > > creation and their name before doing the work. > > > > > > > > > > Any objection? > > > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > Le mercredi 25 janvier 2023, 11:15:08 CET Guillaume Nodet a écrit : > > > > > > That sounds like a good plan. > > > > > > > > > > > > A few observations: > > > > > > * the usage of the plexus xml classes should be deprecated along > > with > > > > > > > > > > the > > > > > > > > > > > v3 model once the v4 api is stabilized and matured imho > > > > > > > > > > > > * this will introduce a release cycle between maven-core / > > > > > > > > > > plexus-utils, > > > > > > > > > > > which is not really clean even though it should not cause any real > > > > > > > > > > problem > > > > > > > > > > > Guillaume > > > > > > > > > > > > Le ven. 30 déc. 2022 à 23:56, Hervé Boutemy <[email protected]> > > a > > > > > > > > > > > > écrit : > > > > > > > ok, if everyone wants to go that route of clarifying dependency > > from > > > > > > > > > > Maven > > > > > > > > > > > > on > > > > > > > plexus-utils, let's go and do it fully. > > > > > > > > > > > > > > First, I'm lost if you call "plexus-xml" an artifact that is > > > > > > > > > > maintained at > > > > > > > > > > > > Maven. So we'll need to rephrase with one strict convention: > > plexus-* > > > > > > > artifacts are maintained at Plexus, maven-* are maintained at > > Maven. > > > > > > > > > > > > I was originally thinking about a new plexus artifact, but a maven > > one > > > > > > would be better. > > > > > > > > > > > > > Then let's define where the strong dependency is: > > > > > > > correct me if I'm wrong, Maven core provides 5 classes from > > > > > > > > > > plexus-utils > > > > > > > > > > > > 3.x > > > > > > > to the whole plugins/extensions ecosystem [1]: > > > > > > > 1. org.codehaus.plexus.util.xml.Xpp3Dom > > > > > > > 2. org.codehaus.plexus.util.xml.Xpp3DomBuilder > > > > > > > 3. org.codehaus.plexus.util.xml.pull.XmlPullParser > > > > > > > 4. org.codehaus.plexus.util.xml.pull.XmlPullParserException > > > > > > > 5. org.codehaus.plexus.util.xml.pull.XmlSerializer > > > > > > > (it was only 4 classes in Maven 3, but Xpp3DomBuilder was added > > in > > > > > > > > > > Maven > > > > > > > > > > > > 4) > > > > > > > > > > > > > > then for compatibility reason these 5 classes can't have their > > public > > > > > > > > > > API > > > > > > > > > > > > changed = it is the only place where there is a strong > > dependency from > > > > > > > whole > > > > > > > Maven to Plexus Utils > > > > > > > Because if any plugin uses an implementation at build time (old > > > > > > > > > > version, > > > > > > > > > > > > for > > > > > > > example), at runtime, Maven core injects the Maven core provided > > > > > > > > > > classes. > > > > > > > > > > > > For everything else that is available in Plexus Utils, we have > > > > > > > maven-shared- > > > > > > > utils that was created years ago and that was globally ignored > > [2]. > > > > > > > If people want to migrate, they just can for years, > > independently in > > > > > > > > > > each > > > > > > > > > > > > plugin or even in Maven core. > > > > > > > > > > > > > > > > > > > > > If we want to have a clean state, we can implement these 5 > > classes in > > > > > > > > > > the > > > > > > > > > > > > current maven-xml-impl, that I propose to name > > maven-plexus-utils-xml, > > > > > > > > > > or > > > > > > > > > > > > shorter maven-plexus-xml. > > > > > > > As the artifact name tells, it is maintained at Maven level. And > > "of > > > > > > > course", > > > > > > > it MUST NOT depend on Plexus Utils given the intent of getting > > out of > > > > > > > > > > that > > > > > > > > > > > > dependency... > > > > > > > It is expected to be very stable, because it is a key > > compatibility > > > > > > > contract > > > > > > > between Maven core and the whole plugins/extensions ecosystem: > > > > > > > could/should be > > > > > > > extracted from Maven core releases, moved to shared/ components. > > > > > > > > > > > > Makes sense. > > > > > > > > > > > > > At Plexus Utils level, I propose that we (the Plexus org) do a > > version > > > > > > > > > > 4 > > > > > > > > > > > > that > > > > > > > removes the 5 classes, replacing with a dependency on > > maven-plexus-xml > > > > > > > that > > > > > > > was written in Maven. > > > > > > > Then when Maven core migrates to plexus-utils 4, it remove the > > current > > > > > > > need to > > > > > > > have inside Maven core a local shaded "plexus-utils" (that > > should have > > > > > > > been > > > > > > > named maven-plexus-utils for clarity) [3] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is that plan clear and accurate? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > https://github.com/apache/maven/blob/master/maven-core/src/main/resources/ > > > > > > > > > > > > META-INF/maven/extension.xml#L85 > > > > > > > < > > > > > > > > > > > > https://github.com/apache/maven/blob/master/maven-core/src/main/resources > > > > > > > > > > > > /META-INF/maven/extension.xml#L85> > > > > > > > > > > > > > > [2] https://maven.apache.org/shared/maven-shared-utils/ > > > > > > > > > > > > > > [3] https://github.com/apache/maven/tree/master/plexus-utils > > > > > > > > > > > > > > Le vendredi 30 décembre 2022, 16:44:49 CET Guillaume Nodet a > > écrit : > > > > > > > > To reduce dependency from maven to plexus, we could keep the > > xml api > > > > > > > > > > and > > > > > > > > > > > > > implementation which are used by maven 4 inside maven, and > > update > > > > > > > > plexus-utils (or the new plexus-xml) to be compatible with the > > new > > > > > > > > immutable DOM api from maven. > > > > > > > > > > > > > > > > So this would mean: > > > > > > > > * move the two re-implemented plexus classes from maven to a > > new > > > > > > > > > > > > > > > > plexus-xml project: > > > > > > > https://github.com/apache/maven/tree/master/maven-xml-impl/src/main/java/o > > > > > > > > > > > > rg> > > > > > > > > > > > > > > > /codehaus/plexus/util/xml > > > > > > > > > > > > > > > > * plexus-xml would depend on maven-api-xml and > > maven-xml-impl (or > > > > > > > > > > > > > > > > whatever it will be renamed) > > > > > > > > > > > > > > > > * modify plexus-utils to depend on plexus-xml > > > > > > > > > > > > > > > > One plexus-xml and plexus-utils are released, this would allow > > to > > > > > > > > > > remove > > > > > > > > > > > > > from maven: > > > > > > > > * the two xml classes > > > > > > > > * the repackaged plexus-utils > > > > > > > > > > > > > > > > Le ven. 30 déc. 2022 à 16:21, Benjamin Marwell < > > [email protected]> > > > > > > > > > > a > > > > > > > > > > > > > écrit : > > > > > > > > > +1 to what Romain said. Let's reduce dependencies to other > > orgs > > > > > > > > > > where > > > > > > > > > > > > > > possible and feasible. It is, in this case. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 30 Dec 2022, 10:27 Romain Manni-Bucau, < > > > > > > > > > > [email protected]> > > > > > > > > > > > > > > wrote: > > > > > > > > > > Hi Hervé, > > > > > > > > > > > > > > > > > > > > As mentionned in the thread I think it makes sense to > > freeze > > > > > > > > > > plexus > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > slowly import to maven the related code so I'd be to > > import the > > > > > > > > > > > > > > parts we > > > > > > > > > > > > > > > > > need (guess some abstraction can be dropped at the same > > time). > > > > > > > > > > So +1 to split, -0 to do it at plexus, +1 to do it in > > maven. > > > > > > > > > > > > > > > > > > > > Romain Manni-Bucau > > > > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > > > > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > > > > > > > > <http://rmannibucau.wordpress.com> | Github < > > > > > > > > > > https://github.com/rmannibucau> | > > > > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > > > > > > > < > > > > > > > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performanc > > > > > > > > > > > > > > e > > > > > > > > > > > > > > > > > > > Le ven. 30 déc. 2022 à 10:22, Hervé Boutemy < > > > > > > > > > > [email protected]> > > > > > > > > > > > > a > > > > > > > > > > > > > > > > > écrit : > > > > > > > > > > > while working on the XML side of Maven 4 immutable API, > > we had > > > > > > > > > > the > > > > > > > > > > > > > > > > idea > > > > > > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > > > > > extracting the XML code from plexus-utils to a new > > separate > > > > > > > > > > > > > > plexus-xml > > > > > > > > > > > > > > > > > > artifact > > > > > > > > > > > that could be done for version 4 > > > > > > > > > > > > > > > > > > > > > > see > > https://github.com/codehaus-plexus/plexus-utils/issues/228 > > > > > > > > > > > > > > > > > > > > > > any objection? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > > > For additional commands, e-mail: > > [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > -- > > Elliotte Rusty Harold > > [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > ------------------------ > Guillaume Nodet -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
