jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
Signup
Maven 2.x Release Plugin
  • Maven 2.x Release Plugin
  • MRELEASE-201

Deployed POM is not valid XML

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 2.0-beta-8
  • Component/s: None
  • Labels:
    None
  • Testcase included:
    yes
  • Number of attachments :
    1

Description

If the POM has utf-8 encoding and you make usage of entities to support extended characters, these characters are no longer encoded as entities in the repository (well, the effect is already visible in target/effective-pom.xml). This is not a rule of general, POMs with packaging "pom" are installed and deployed correctly.

Multi module example. The attached archive contains a parent POM and a POM for a jar. Both UTF-8 encoded POMs contain a developer with a name using an entitiy. Releasing the POMs they are written with the expanded entitiy making the XML invalid.

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

Attachments

  1. Hide
    Zip Archive
    MNG-2362.zip
    28/Feb/07 7:29 AM
    1.0 kB
    Jörg Schaible
    1. XML File
      MNG-2362/issue/pom.xml 0.8 kB
    2. XML File
      MNG-2362/pom.xml 0.7 kB
    Download Zip
    Show
    Zip Archive
    MNG-2362.zip
    28/Feb/07 7:29 AM
    1.0 kB
    Jörg Schaible

Issue Links

is related to

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. MRELEASE-87 Poms are written with wrong encodings

  • 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.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Benjamin Bentmann added a comment - 10/Dec/07 4:06 AM

Another encoding problem: The plugin (2.0-beta-7) does not output an XML declaration in the rewritten POM. While this might be acceptable for UTF-8 encoded POMs (although I would consider it a betst practice to always output an XML declaration), it is in general wrong for any other encoding.

Show
Benjamin Bentmann added a comment - 10/Dec/07 4:06 AM Another encoding problem: The plugin (2.0-beta-7) does not output an XML declaration in the rewritten POM. While this might be acceptable for UTF-8 encoded POMs (although I would consider it a betst practice to always output an XML declaration), it is in general wrong for any other encoding.
Hide
Permalink
Nathan Beyer (Cerner) added a comment - 10/Dec/07 11:01 AM

+1 for ALWAYS including an XML prolog that includes the encoding.

Since the POM file are often retrieve via HTTP, the lack of the encoding in the POM can be even more troublesome, as the encoding can be determined by the transport [1] if it's not in the XML prolog, so the "default" of UTF-8 doesn't always apply. This means that the encoding maybe determined by default content-type values set in the web server's configuration. This adds a significant amount of variability, which would be eliminated by explicitly setting the encoding in the prolog.

[1] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-prolog-dtd

Show
Nathan Beyer (Cerner) added a comment - 10/Dec/07 11:01 AM +1 for ALWAYS including an XML prolog that includes the encoding. Since the POM file are often retrieve via HTTP, the lack of the encoding in the POM can be even more troublesome, as the encoding can be determined by the transport [1] if it's not in the XML prolog, so the "default" of UTF-8 doesn't always apply. This means that the encoding maybe determined by default content-type values set in the web server's configuration. This adds a significant amount of variability, which would be eliminated by explicitly setting the encoding in the prolog. [1] http://www.w3.org/TR/2006/REC-xml-20060816/#sec-prolog-dtd
Hide
Permalink
Benjamin Bentmann added a comment - 23/May/08 1:01 PM

Fixed by MRELEASE-87. While the entities are still expanded by the Release Plugin, they are now properly encoded as given by the XML declaration (which is kept now).

Show
Benjamin Bentmann added a comment - 23/May/08 1:01 PM Fixed by MRELEASE-87 . While the entities are still expanded by the Release Plugin, they are now properly encoded as given by the XML declaration (which is kept now).

People

  • Assignee:
    Benjamin Bentmann
    Reporter:
    Jörg Schaible
Vote (4)
Watch (2)

Dates

  • Created:
    28/Feb/07 7:29 AM
    Updated:
    23/May/08 1:01 PM
    Resolved:
    23/May/08 1:01 PM
  • Atlassian JIRA (v5.2.7#850-sha1:b2af0c8)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.