[MNG-7655] Get rid of org.apache.maven:plexus-utils

[jira-importer]

Hervé Boutemy opened MNG-7655 and commented

in #829 , Maven's internal plexus-utils repackaging is used, switching from Plexus original org.codehaus.plexus:plexus-utils to org.apache.maven:plexus-utils

this switch keeping the exact same artifactId but just changing only the groupId is confusing: we need another artifactId

maven-plexus-utils?

---

Affects: 4.0.0-alpha-2

Issue Links:

• MNG-7732 org.codehaus.plexus.util.xml package shouldn't be in core

• MNG-7660 Rename Dom to XmlNode in the v4 api

Remote Links:

• GitHub Pull Request #1093
  
• GitHub Pull Request #942
  

Backported to: 4.0.0-alpha-7

[jira-importer]

Hervé Boutemy commented

discussion on dev ML https://lists.apache.org/thread/t52x7jfqlfxwtftbwv4vpfhqg6zgsysf

[jira-importer]

Hervé Boutemy commented

other ideas found during discussion: rename Dom interface to XmlNode MNG-7660, rename maven-api-meta to maven-api-annotations

[jira-importer]

Elliotte Rusty Harold commented

I'm OK with keeping the artifact ID org.apache.maven:plexus-utils

I am not OK with keeping the package names the same. The current work seems likely to cause major problems with split packages in JDK 9+ and classpath conflicts and dimaond dependency problems in all JDKs.

https://jlbp.dev/JLBP-6

[jira-importer]

Hervé Boutemy commented

keeping 4 XML parsing classes as-is is a MUST =

<!-- plexus-utils (for DOM-type fields in maven-model) -->
    <exportedPackage>org.codehaus.plexus.util.xml.Xpp3Dom</exportedPackage>
    <exportedPackage>org.codehaus.plexus.util.xml.pull.XmlPullParser</exportedPackage>
    <exportedPackage>org.codehaus.plexus.util.xml.pull.XmlPullParserException</exportedPackage>
    <exportedPackage>org.codehaus.plexus.util.xml.pull.XmlSerializer</exportedPackage>

from https://maven.apache.org/ref/3.9.0/maven-core/core-extensions.html

[jira-importer]

Elliotte Rusty Harold commented

You can only keep them as is by leaving the package names, class name AND maven coordinates the same. If you change the Maven coordinates (group ID, artifact ID) but leave the fully qualified class name the same, users will experience broken builds and bugs due to classpath conflicts, diamond dependency problems, and loading unexpected versions of the classes.

I understand that it might be necessary not to change the package name, but in that case they have to be published in the same artifact.

[jira-importer]

Hervé Boutemy commented

I don't get why you could change the groupId but not the artifactId: everything in Maven core classloader does not care about Maven coordinate, nor does the exports in API classloader.
You should read https://maven.apache.org/guides/mini/guide-maven-classloading.html and dig into mechanisms for exports

[jira-importer]

Elliotte Rusty Harold commented

You're right. You can't (well, shouldn't) change either group ID or artifact ID without changing the package or class name as well. General principle of Java: do not put the same class in two different jars in the classpath. Maven and Gradle can keep this from happening when the different jars have the same group ID and artifact ID but not when those are changed.

In Java 9+ the rules get even stronger. You shouldn't put different classes from the same package in two different jars. I'm not sure if the Maven class loader will avoid this problem for Maven, but it absolutely does not for any other project that does not use the Maven class loader but does depend on these artifacts.

It is not simply the Maven core classloader that is affected here, but every project that depends on any of these dependencies, whether it uses Maven or not.

https://jlbp.dev/JLBP-6

[jira-importer]

Hervé Boutemy commented

ok, you don't understand the specific case of this artifact in Maven core, you don't want to understand, you just want to block
that's your choice: I'm stopping loosing time trying to explain (yes, it's not obvious)