Maven 1.x Changes Plugin
  1. Maven 1.x Changes Plugin
  2. MPCHANGES-24

The encoding of the changes.xml file is not preserved after doing release-version

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.1
    • Fix Version/s: 1.6
    • Labels:
      None
    • Environment:
      Windows XP Pro, Maven 1.0.2, Changes-plugin 1.5.1.
    • Number of attachments :
      1

      Description

      I thought that I would finally take the plunge and use the scm-plugin to do a release. After making sure that all files had been checked into version control, it began changing the project.xml and changes.xml files. For some reason this didn't go well, but that might be another Jira issue later on.

      The scm-plugin uses the changes-plugin to transform the changes.xml file by inserting the correct date for the release being made. The changes-plugin reads, transforms and then writes the file back again. This means that some formating is lost and whitespace changes are made, which is OK.

      However the encoding of the original changes.xml file is not preserved when it is written back after the transformation. This meant that my file was converted from ISO-8859-1 to UTF-8, which is the default encoding used by dom4j. Without a UTF-8 compliant editor I can't edit the file any more, because I use non-us-ascii character in the file.

      I tried to make a patch (see attached file) but I wasn't very successful. The attached file should be treated as psudo-code because the actual method that I call doesn't exist in the Document class in dom4j. The point of the attachment is to show what should be done. I am not familiar enough with dom4j to solve it myself, sorry. Maybe someone else has an idea of what needs to be done?

      1. encoding.patch
        0.5 kB
        Dennis Lundberg

        Issue Links

          Activity

          Hide
          Lukas Theussl added a comment -

          Dom4j 1.4 does not allow for an easy extraction of the document encoding, this was only added in version 1.5. An upgrade of dom4j has been attempted for Maven (see MAVEN-1345) but failed for several reasons.

          To work around the current issue I have rewritten the transformation routine to use Maven's default output encoding, maven.docs.outputencoding, which can be specified as a property.

          Show
          Lukas Theussl added a comment - Dom4j 1.4 does not allow for an easy extraction of the document encoding, this was only added in version 1.5. An upgrade of dom4j has been attempted for Maven (see MAVEN-1345 ) but failed for several reasons. To work around the current issue I have rewritten the transformation routine to use Maven's default output encoding, maven.docs.outputencoding, which can be specified as a property.
          Hide
          Dennis Lundberg added a comment -

          This is a good enough solution for my needs.
          Thank you Lukas!

          Show
          Dennis Lundberg added a comment - This is a good enough solution for my needs. Thank you Lukas!
          Hide
          Dennis Lundberg added a comment -

          I have just made a release with Maven using the SVN trunk version of the changes plugin. After setting maven.docs.outputencoding=ISO-8859-1 it works fine for me. Thanks again.

          Show
          Dennis Lundberg added a comment - I have just made a release with Maven using the SVN trunk version of the changes plugin. After setting maven.docs.outputencoding=ISO-8859-1 it works fine for me. Thanks again.
          Hide
          Lukas Theussl added a comment -

          You shouldn't even have to set the property since ISO-8859-1 is the default value for maven.docs.outputencoding. But anyway, glad that it works!

          Show
          Lukas Theussl added a comment - You shouldn't even have to set the property since ISO-8859-1 is the default value for maven.docs.outputencoding. But anyway, glad that it works!

            People

            • Assignee:
              Unassigned
              Reporter:
              Dennis Lundberg
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: