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.

        Issue Links

          Activity

          Hide
          Benjamin Bentmann added a comment -

          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 - 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
          Nathan Beyer (Cerner) added a comment -

          +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 - +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
          Benjamin Bentmann added a comment -

          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 - 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
            • Votes:
              4 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: