Maven
  1. Maven
  2. MNG-3556

XML entity not supported in Maven 2

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: General
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      1

      Description

      The attached XML file defines and uses an XML entity called "&blah;". It validates in FF and in other XML parsers, but when I attempt to load it up in Maven, I get the fellowing exception:

      [INFO] Scanning for projects...
      [INFO] ------------------------------------------------------------------------
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] Error building POM (may not be this project's POM).
      
      
      Project ID: unknown
      POM Location: C:\blah\pom.xml
      
      Reason: Parse error reading POM. Reason: could not resolve entity named 'blah' (position: START_TAG seen ...</version>\r\n  <name>&blah;... @11:15)  for project unknown at C:\blah\pom.xml
      
      
      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. Reason: could not resolve entity named 'blah' (position: START_TAG seen ...</version>\r\n  <name>&blah;... @11:15)  for project unknown at C:\blah\pom.xml
              at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:376)
              at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:289)
              at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
              at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              at java.lang.reflect.Method.invoke(Method.java:597)
              at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
              at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
              at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
              at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
      Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: could not resolve entity named 'blah' (position: START_TAG seen ...</version>\r\n  <name>&blah;... @11:15)  for project unknown at C:\blah\pom.xml
              at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1416)
              at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1377)
              at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:474)
              at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:197)
              at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:548)
              at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:458)
              at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:362)
              ... 11 more
      Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: could not resolve entity named 'blah' (position: START_TAG seen ...</version>\r\n  <name>&blah;... @11:15)
              at org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1282)
              at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1093)
              at org.codehaus.plexus.util.xml.pull.MXParser.nextText(MXParser.java:1058)
              at org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2050)
              at org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4422)
              at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1412)
              ... 17 more
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: < 1 second
      [INFO] Finished at: Mon Apr 28 14:43:06 PDT 2008
      [INFO] Final Memory: 1M/4M
      [INFO] ------------------------------------------------------------------------
      
      1. pom.xml
        0.5 kB
        Dan Fabulich

        Activity

        Hide
        Jörg Schaible added a comment -

        AFAICS entity support was dropped for M2 intentionally, since it allows you to create POMs that are no longer self contained. Side-effect is also a speed-up in XML processing

        Show
        Jörg Schaible added a comment - AFAICS entity support was dropped for M2 intentionally, since it allows you to create POMs that are no longer self contained. Side-effect is also a speed-up in XML processing
        Hide
        Brett Porter added a comment -

        moving off to the future in case we ever switch xml parsers

        Show
        Brett Porter added a comment - moving off to the future in case we ever switch xml parsers
        Hide
        Manuel EVENO added a comment -

        Related to this proposal : http://docs.codehaus.org/display/MAVENUSER/Optional+support+for+splitting+up+pom.xml+in+multiple+files

        I known it would allow us to create POMs that are no longer self contained but maintaining huge parent pom is a mess.
        When you have dependencyManagement + pluginManagement + build + reporting ... fully configured, parent pom is really hard to maintain.

        The solution we have, is to create an artificial hierarchy to split the pom

        • common-build
          • common-dependencyManagement (with maybe pluginManagement too)
          • common-reporting

        So, in this case, the fact is we already split the pom to be able to maintain it.

        Perhaps you could allow pom splitting only for project of 'pom' packaging type ....

        Show
        Manuel EVENO added a comment - Related to this proposal : http://docs.codehaus.org/display/MAVENUSER/Optional+support+for+splitting+up+pom.xml+in+multiple+files I known it would allow us to create POMs that are no longer self contained but maintaining huge parent pom is a mess. When you have dependencyManagement + pluginManagement + build + reporting ... fully configured, parent pom is really hard to maintain. The solution we have, is to create an artificial hierarchy to split the pom common-build common-dependencyManagement (with maybe pluginManagement too) common-reporting So, in this case, the fact is we already split the pom to be able to maintain it. Perhaps you could allow pom splitting only for project of 'pom' packaging type ....
        Hide
        Shane Isbell added a comment -

        We are pretty close to having this fixed. Most of parsing for 3.0 is using woodstox. There are just a couple of spots left to clean up.

        Show
        Shane Isbell added a comment - We are pretty close to having this fixed. Most of parsing for 3.0 is using woodstox. There are just a couple of spots left to clean up.
        Hide
        Jason van Zyl added a comment -

        By design we don't support entities.

        Show
        Jason van Zyl added a comment - By design we don't support entities.
        Hide
        Matt DeBoer added a comment -

        It has been mentioned that the reason for not supporting XML entities is that it provides capability to create a non-self-contained pom.
        That argument doesn't apply to internal XML entities. Is there some reason support for these was thrown out along with external entities?

        Show
        Matt DeBoer added a comment - It has been mentioned that the reason for not supporting XML entities is that it provides capability to create a non-self-contained pom. That argument doesn't apply to internal XML entities. Is there some reason support for these was thrown out along with external entities?
        Hide
        Brett Porter added a comment -

        Matt: combination of lack of parser support at the time in conjunction with the decision not to use it. My only thought at this stage some years later might be tool support. Regardless, it would be far better to focus on shipping support for more concise formats or ways to compose the model of other external fragments in a generic fashion rather than relying on XML tooling specifically.

        Show
        Brett Porter added a comment - Matt: combination of lack of parser support at the time in conjunction with the decision not to use it. My only thought at this stage some years later might be tool support. Regardless, it would be far better to focus on shipping support for more concise formats or ways to compose the model of other external fragments in a generic fashion rather than relying on XML tooling specifically.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dan Fabulich
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: