Maven 2 & 3

Use a external XML Pull parser instead of plexus one

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Fixed
  • Affects Version/s: 2.0.4
  • Fix Version/s: 3.0-alpha-1
  • Component/s: POM
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

To avoid maintaining the plexus XMLPullParser we should move to a standard implementation like StaX

As mentioned in DOXIA-60:

There's a performance white paper
http://java.sun.com/performance/reference/whitepapers/StAX-1_0.pdf

The best implementation seems to be http://woodstox.codehaus.org/

Another nice set of utilities at http://wiki.java.net/bin/view/Javawsxml/StaxUtilsProject

The indentator could be used instead of the PrettyPrintXMLWriter

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MEVENIDE-449 Mevenide plugin stumbels upon non ASCII characters in the path to the .m2 directory

  • Major - Major loss of function.
  • Resolved - A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.
is related to

Bug - A problem which impairs or prevents the functions of the product. MNG-4708 I am not able to add name space prefixes to pom.xml

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. MNG-2593 Maven 2 stumbels upon non ASCII characters in the value of a <localRepository> value in the $HOME/.m2/settings.xml

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2362 Deployed POM is not valid XML

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2057 The Maven 2.0.2 XML parser fails to parse a UTF-8 POM that begins with the optional byte-order mark.

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2254 the encoding parameter in xml declaration of POM is ignored

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2818 maven 2 requires a UTF-8 locale to build properly

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2769 Use of POM namespace is confused and confusing in both the code and the documentation

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

New Feature - A new feature of the product, which has yet to be developed. MSHARED-255 create DomUtils, equivalent from Xpp3DomUtils but working on W3C DOM

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. DOXIA-60 Use a external XML Pull parser instead of plexus one

  • Critical - Crashes, loss of data, severe memory leak.
  • Open - The issue is open and ready for the assignee to start work on it.

Improvement - An improvement or enhancement to an existing feature or task. MPLUGIN-229 don't use Plexus' Xpp3 in generated HelpMojo to read XML files: XML parser in JDK is sufficient

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
supercedes

Bug - A problem which impairs or prevents the functions of the product. MNG-2715 Maven does not comply to XML rules regarding prefixes.

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. PLXUTILS-11 MXParser can't handle the encoding declaration in XML declaration

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Carlos Sanchez added a comment -

Seems by related issues that people is having a lot of trouble with encodings

Show
Carlos Sanchez added a comment - Seems by related issues that people is having a lot of trouble with encodings
Hide
Permalink
Stefan Hübner added a comment -

Hm, just a thought, but:

To me it seems that the parser used to read in maven's model isn't the problem really. It's more likely the way the POM is handed to the parser.

Have a look to class org.apache.maven.model.io.xpp3.MavenXpp3Reader which is generated by maven-model. This MavenXpp3Reader is invoked via read-method with one parameter. This parameter is a Reader and that, to me, is problematic. Problematic because there's no way once you have a Reader on some inputsource (i.e. a stream) to change that reader's handling of character encodings on it's underlying stream. So, as long as reading the model is invoked by handing a Reader to some parser the parser won't be able to adapt to the actual POM's encoding.

As a conclusion I would recommend model parser should be handed a stream rather than a Reader-instance working on the underlying POM.

I don't know if other parsers can cope with that situation, but XMLPullParser doesn't. It would though, if it is given a stream on the POM, but I don't know which wider implications this would cause.

What do you think?

Show
Stefan Hübner added a comment - Hm, just a thought, but: To me it seems that the parser used to read in maven's model isn't the problem really. It's more likely the way the POM is handed to the parser. Have a look to class org.apache.maven.model.io.xpp3.MavenXpp3Reader which is generated by maven-model. This MavenXpp3Reader is invoked via read-method with one parameter. This parameter is a Reader and that, to me, is problematic. Problematic because there's no way once you have a Reader on some inputsource (i.e. a stream) to change that reader's handling of character encodings on it's underlying stream. So, as long as reading the model is invoked by handing a Reader to some parser the parser won't be able to adapt to the actual POM's encoding. As a conclusion I would recommend model parser should be handed a stream rather than a Reader-instance working on the underlying POM. I don't know if other parsers can cope with that situation, but XMLPullParser doesn't. It would though, if it is given a stream on the POM, but I don't know which wider implications this would cause. What do you think?
Hide
Permalink
Carlos Sanchez added a comment -

Yes, that's part of the solution too

Show
Carlos Sanchez added a comment - Yes, that's part of the solution too
Hide
Permalink
John Casey added a comment -

this will require the implementation of a woodstox (or other StaX parser) plugin for Modello, in order to allow us to generate an appropriate model parser.

Show
John Casey added a comment - this will require the implementation of a woodstox (or other StaX parser) plugin for Modello, in order to allow us to generate an appropriate model parser.
Hide
Permalink
Jason van Zyl added a comment -

From looking at the related issues I think the crux of the problem is using a Reader instead of an InputStream.

Show
Jason van Zyl added a comment - From looking at the related issues I think the crux of the problem is using a Reader instead of an InputStream.
Hide
Permalink
Stefan Hübner added a comment -

IMHO: yes, there's the nail's head, Jason.

Show
Stefan Hübner added a comment - IMHO: yes, there's the nail's head, Jason.
Hide
Permalink
Brett Porter added a comment -

this is now in place in the branch for MNG-3397

Show
Brett Porter added a comment - this is now in place in the branch for MNG-3397
Hide
Permalink
Jason van Zyl added a comment -

We are now using the StAX parser from the Woodstox project.

Show
Jason van Zyl added a comment - We are now using the StAX parser from the Woodstox project.

People

  • Assignee:
    Unassigned
    Reporter:
    Carlos Sanchez
Vote (4)
Watch (4)

Dates

  • Created:
    Updated:
    Resolved: