...
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: MavenProject.getGoalConfiguration for example.
Then it has to let Xpp3Dom leak for plugins to be able to use this API: provides xpp3 objects to plugins, for them to tweak configuration: see 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:
- 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?)
- MODELLO-262: add location tracking feature to StaX reader, since it is actually only available for Xpp3
- MSHARED-255: Maven XML merge feature for these DOM objects
- Plexus container support for these DOM objects?
- 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
+1 | brett |
---|---|
0 |
|
-1 |
|