> The only "problem" is that it > creates a cycle between maven-core and plexus-utils, but....
to reduce the problem, that's why I proposed at plexus-utils level to split the xml part in another plexus-xml artifact, so at least the overlap is reduced and there is clarification about the fact that the problem is only on a few XML classes from Plexus that are provided by Maven core to the whole plugins/extensions ecosystem Then how to solve this cycle on the Plexus-XML extract from Plexus Utils: need to test in a branch... On 2023/01/31 14:43:07 Guillaume Nodet wrote: > Le mar. 31 janv. 2023 à 15:27, Elliotte Rusty Harold <elh...@ibiblio.org> a > écrit : > > > 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. > > > > That was actually my proposal. I.e. keep things where they are, just > add a dependency from plexus-utils to maven-xml-impl / maven-api-xml. > > > > > > 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? > > > > The other red flag is that org.apache.maven:plexus-utils is a repackaged > version (with the modifications I was mentioning earlier) of > org.codehaus.plexus:plexus-utils. Which I think is a red flag too. > > But yes, those artifacts have only been published as alpha. > > So I think my earlier proposal is fine, i.e. remove the plexus classes from > the maven code tree, update them where they belong (i.e. in the plexus > code tree) by adding a dependency to the maven-xml-impl. > This keeps org.apache.maven.* classes in maven, org.codehaus.plexus.* > classes in plexus and everything is fine. The only "problem" is that it > creates a cycle between maven-core and plexus-utils, but.... > > @hboutemy wdyt ? > > > > > > On Tue, Jan 31, 2023 at 7:47 AM Guillaume Nodet <gno...@apache.org> 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 <elh...@ibiblio.org> > > 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 <herve.bout...@free.fr> > > > > 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 < > > herve.bout...@free.fr> 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 < > > herve.bout...@free.fr> > > > > 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 < > > > > bmarw...@apache.org> > > > > > > > > > > > > > > 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, < > > > > > > > > > > > > > > rmannibu...@gmail.com> > > > > > > > > > > > > > > > > > > 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 < > > > > > > > > > > > > > > herve.bout...@free.fr> > > > > > > > > > > > > > > > > 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: > > dev-unsubscr...@maven.apache.org > > > > > > > > > > > > > For additional commands, e-mail: > > > > dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > > > > -- > > > > Elliotte Rusty Harold > > > > elh...@ibiblio.org > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > > > > > > > -- > > > ------------------------ > > > Guillaume Nodet > > > > > > > > -- > > Elliotte Rusty Harold > > elh...@ibiblio.org > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > -- > ------------------------ > Guillaume Nodet > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
