[MNG-7655] maven-plexus-utils and maven-plexus-utils-xml (xml-impl)

[hboutemy]

https://issues.apache.org/jira/browse/MNG-7655

keeping plexus-utils artifactId with org.apache.maven vs org.codehaus.plexus groupId is confusing: let's name it maven-plexus-utils

and maven-xml-impl is better named maven-plexus-utils-xml, to show that it reimplements plexus-utils' content

[gnodet]

https://issues.apache.org/jira/browse/MNG-7655

keeping plexus-utils artifactId with org.apache.maven vs org.codehaus.plexus groupId is confusing: let's name it maven-plexus-utils

and maven-xml-impl is better named maven-plexus-utils-xml, to show that it reimplements plexus-utils' content

I don't have any problem with this PR. However, I wonder that the final outcome should be. In the long term, the repackaging is a bit of a hack and a pain to maintain, especially the xml part which is reimplemented. I see several solutions:

• deprecate the xml part in plexus-utils
• move the implementation to a plexus-utils 3.0 (that would mean that plexus-utils would depend on the xml api from maven
• deprecate plexus-utils artfifact and move the whole code into maven (this could have been beneficial in the maven 3 architecture where plexus-utils was exported, but this is no longer the case in 3.x and the new 4.x api does not depend on the plexus-utils artifact)

[michael-o]

Why not move out the XML stuff to plexus-xml? Plexus Utils is just too large.

[cstamas]

+1 for 3rd option

[cstamas]

Actually, a LOT of plexus should be ingested by maven stuff (as it is unused anywhere else), think compiler, think archiver, etc -- we must collapse these, as it is nightmare and just layers and layers of indirection...

[michael-o]

Actually, a LOT of plexus should be ingested by maven stuff (as it is unused anywhere else), think compiler, think archiver, etc -- we must collapse these, as it is nightmare and just layers and layers of indirection...

Too much pain, too much work!

[hboutemy]

yes, splitting Plexus' plexus-utils 4.0.0 https://github.com/codehaus-plexus/plexus-utils into plexus-xml + plexus-utils makes sense
because AFAIK Maven core exports plexus-xml only, not the plexus-utils other classes, which are only internal hidden utils

then on how to evolve plexus-xml extracted from plexus-utils with the rewrite for Maven 4, good question

first issue created codehaus-plexus/plexus-utils#228

[rmannibucau]

+1 for maven to ingest used plexus classes rather than working on plexus off radars for the long term (probably lazily, ie each time we need a change we rather import the lib instead of patching+releasing it).

[hboutemy]

oh, back to plexus-utils https://codehaus-plexus.github.io/plexus-utils/ vs maven-shared-utils https://maven.apache.org/shared/maven-shared-utils/ discussion

I suppose we can split maven-shared-utils 3 into maven-shared-xml 4 + maven-shared-utils 4

using maven-shared-utils 4 instead of plexus-utils 4 in Maven core is not an issue

but switching to maven-shared-xml 4 is not possible, because there is a java package change from plexus-xml 4

[hboutemy]

ok, launching some feedback on the Maven dev ML for plexus-xml: this looks simple and wold make things much cleaner = Plexus plexus-utils 4 is used as is (and eventually migrated away), and there is only the plexus-xml reimplementation as maven-plexus-xml

[gnodet]

Superseded by #1093