XML entity not supported in Maven 2

Details

Type: Bug
Status: Closed
Priority: 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] ------------------------------------------------------------------------

Options
- Sort By Name
- Sort By Date
- Ascending
- Descending
- Download All

Attachments

pom.xml

28/Apr/08 4:52 PM

0.5 kB

Dan Fabulich

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

J�rg Schaible added a comment - 29/Apr/08 2:08 AM

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 - 29/Apr/08 2:08 AM 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

Permalink

Brett Porter added a comment - 12/Jun/08 5:44 PM

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

Show

Brett Porter added a comment - 12/Jun/08 5:44 PM moving off to the future in case we ever switch xml parsers

Hide

Permalink

Manuel EVENO added a comment - 04/Jul/08 3:48 AM

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 - 04/Jul/08 3:48 AM 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

Permalink

Shane Isbell added a comment - 02/Oct/08 12:41 AM

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 - 02/Oct/08 12:41 AM 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

Permalink

Jason van Zyl added a comment - 29/Dec/09 8:29 PM

By design we don't support entities.

Show

Jason van Zyl added a comment - 29/Dec/09 8:29 PM By design we don't support entities.

Hide

Permalink

Matt DeBoer added a comment - 28/Mar/12 7:41 PM

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 - 28/Mar/12 7:41 PM 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

Permalink

Brett Porter added a comment - 28/Mar/12 10:02 PM

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 - 28/Mar/12 10:02 PM 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

Vote (1)

Watch (1)

Dates

Created:

28/Apr/08 4:52 PM

Updated:

28/Mar/12 10:02 PM

Resolved:

29/Dec/09 8:29 PM