maven-cli exposes third party dependency in public API

[elharo]

Affected version

HEAD

Bug description

Consider if we really want core maven functionality to depend on non-Apache third party projects:

import eu.maveniverse.domtrip.Document;
import eu.maveniverse.domtrip.Editor;
import eu.maveniverse.domtrip.Element;

import static eu.maveniverse.domtrip.maven.MavenPomElements.Elements.MODEL_VERSION;
import static eu.maveniverse.domtrip.maven.MavenPomElements.ModelVersions.MODEL_VERSION_4_0_0;
import static eu.maveniverse.domtrip.maven.MavenPomElements.ModelVersions.MODEL_VERSION_4_1_0;
import static eu.maveniverse.domtrip.maven.MavenPomElements.ModelVersions.MODEL_VERSION_4_2_0;
import static eu.maveniverse.domtrip.maven.MavenPomElements.SchemaLocations.MAVEN_4_0_0_SCHEMA_LOCATION;
import static eu.maveniverse.domtrip.maven.MavenPomElements.SchemaLocations.MAVEN_4_1_0_SCHEMA_LOCATION;
import static eu.maveniverse.domtrip.maven.MavenPomElements.SchemaLocations.MAVEN_4_2_0_SCHEMA_LOCATION;


/**
 * Utility class for handling Maven model version operations during upgrades.
 *
 * <p>This class uses domtrip internally for superior formatting preservation
 * and simplified API while maintaining the same external interface.
 */
public final class ModelVersionUtils {

I'm not sure how far the issue extends. In this file it would be trivial to remove this dependency.

[elharo]

There are about three uses of classes that might be helpful and are worth further consideration, but most of the uses are constants of limited value that can be inlined or replaced:

https://github.com/search?q=repo%3Aapache%2Fmaven%20eu.maveniverse.domtrip.maven&type=code

[elharo]

also noted that ModelVersionUtils exposes third party domtrip in its public API. This is really risky. An implementation we can always swap out. Public API can't be easily changed though. We've had similar issues with jline, jfuse, plexus, and other third party dependencies over the years.

[gnodet]

The classes mentioned (ModelVersionUtils, DomUtils, PomDiscovery, etc.) are all in the org.apache.maven.cling.invoker.mvnup.goals package, which lives in the impl/maven-cli module. This is an implementation module, not part of Maven's public API.

Maven's public API is defined as the org.apache.maven.api.* packages, located in the api/ modules. These are the packages we commit to keeping stable and free of third-party type leakage. Implementation modules (impl/maven-core, impl/maven-impl, impl/maven-cli) are, by design, implementation details.

For context, third-party types are exposed in public method signatures throughout the implementation modules — this is not unique to domtrip:

• Eclipse Aether types (RepositorySystemSession, RemoteRepository, Artifact, DependencyNode, etc.) are extensively used in InternalSession, AbstractSession, MavenSession, MavenProject, PluginPrefixRequest, and many more classes in impl/maven-impl and impl/maven-core
• Plexus types (Xpp3Dom, ClassRealm) are exposed in MojoExecution and MavenProject
• Guice (@ScopeAnnotation, Module) is exposed in @SessionScoped, @MojoExecutionScoped, and ExtensionConfigurationModule

These are all practical necessities for plugin and extension authors using the implementation layer. Wrapping or hiding all of them would add significant complexity for no real benefit — consumers of these modules already accept the transitive dependency tree.

That said, we can reduce the visibility of the mvnup utility classes (e.g., make DomUtils, ModelVersionUtils package-private) since they are only used within their own package. This would address the specific concern without broader impact.

Claude Code on behalf of Guillaume Nodet

[elharo]

Maven's public API are classes and methods marked public. Full stop. Wishing otherwise doesn't make it so. The Aether, Guice, and Plexus types have indeed been problems for years for pretty much the same reasons. Let's not make it worse.

apache/maven-mvnd#1538

[cstamas]

No, they are not. Assuming otherwise is digging your head in sand. You can assume this, as you can (mis) use them, but according to that, all knife manufacturers are producing weapons too, which is hilarious. And if you do all this, sorry, you are on your own, as you do something we explicitly state is wrong to do.

https://maveniverse.eu/blog/2026/03/21/principles-used-to-build-maven/

Also, we document all this. Same principles.
https://maven.apache.org/resolver/api-compatibility.html

[elharo]

And yet somehow we can't even keep this straight in Maven's own projects and end up depending on public APIs marked impl or internal. Hyrum's Law applies.