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. 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] > > -- ------------------------ Guillaume Nodet
