Use StAX instead of XPP3

Context

Maven currently distributes xpp3 parser, baked into the plexus utilities JAR.

However, StAX is a comparable standard that has multiple implementations, including being distributed in Java 6. Much of the toolchain has already been updated to handle it, such as Modello.

This could serve as an equally performant replacement while removing the maintenance burden of our own XML parser.

Solution

Replace the xpp3 parsers in the maven-model with the stax generated parsers.

With the proper separation of plugins, this will not impact plugins that use the xpp3 based parser.

Note that to achieve the benefit of reducing the distribution size, plexus and plexus utilities will need the same modification.

Note that DOM model type is represented as Xpp3Dom object both for XPP3 and StAX Modello-generated parsers.

xpp3 intentionally leaks from core

Maven core internally uses Xpp3Dom objects created by Modello's code generated from pom's model for configuration DOM fields: see ConfigurationContainer.getConfiguration().

This internal representation leaks later in Maven public API: http://maven.apache.org/ref/3.0.4/maven-core/apidocs/org/apache/maven/project/MavenProject.html#getGoalConfiguration(java.lang.String, java.lang.String, java.lang.String, java.lang.String) for example.

Then it has to let Xpp3Dom leak for plugins to be able to use this API: http://maven.apache.org/ref/3.0.4/maven-core/xref/org/apache/maven/classrealm/DefaultClassRealmManager.html#196

(example yet to be shown of plugins getting the configuration from core as Object then casting to Xpp3Dom)

To be able to remove xpp3, we need:

1. MODELLO-260: Modello support to represent DOM content in another format than Xpp3Dom: still need to choose the best one (DOM's Element as it is in JDK since 1.4? Another because of DOM limitations?)
2. MSHARED-255: Maven XML merge feature for these DOM objects
3. Plexus container support for these DOM objects?
4. a helper for these plugins that will support both xpp3 and the new DOM representation and protect them from core move from one to the other.

Notice that some Xpp3 use case don't require Xpp3 from core, but could be independant: for example, HelpMojo code generated by plugin-tools read an XML file, which has nothing shared with the core.

Votes