Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0-beta-4, 2.0-beta-5, 2.0-beta-6
    • Fix Version/s: 2.0-beta-8
    • Component/s: None
    • Labels:
      None
    • Patch Submitted:
      Yes
    • Number of attachments :
      2

      Description

      I have committed a test that works in my Sun and IBM JDKs under windows but breaks in the Continuum at codehaus.
      Tomorrow i'll try with IBM JDK under linux.

      1. MRELEASE-87.diff
        4 kB
        Herve Boutemy
      2. MRELEASE-87-bis.diff
        6 kB
        Herve Boutemy

        Issue Links

          Activity

          Hide
          Jrg Schaible added a comment -

          It is even worse. Even if the POM contains a valid xml declaration with utf-8 as encoding, the plugin writes an invalid XML file! Just add a developer with a name containing a German umlaut like '' or any other character expressed with an entity (here the EURO symbol):

          <name>ö &xf6; €</name>

          the saved pom.xml contains after preparation

          <name> *</name>

          where '*' is the replacement character for a non-displayable character.

          Show
          Jrg Schaible added a comment - It is even worse. Even if the POM contains a valid xml declaration with utf-8 as encoding, the plugin writes an invalid XML file! Just add a developer with a name containing a German umlaut like '' or any other character expressed with an entity (here the EURO symbol): <name>ö &xf6; €</name> the saved pom.xml contains after preparation <name> *</name> where '*' is the replacement character for a non-displayable character.
          Hide
          Jrg Schaible added a comment -

          JIRA did some own interpretation of the last comment, so the name of the developer contained originally:

          <name>&ouml; &#xf6; &#x20AC;</name>
          
          Show
          Jrg Schaible added a comment - JIRA did some own interpretation of the last comment, so the name of the developer contained originally: <name>&ouml; &#xf6; &#x20AC;</name>
          Hide
          Carlos Sanchez added a comment -

          I wrote a test, testWritePom in PrepareReleaseMojoTest
          i have commented it because it succeeds under win and fails on linux continuum and

          Show
          Carlos Sanchez added a comment - I wrote a test, testWritePom in PrepareReleaseMojoTest i have commented it because it succeeds under win and fails on linux continuum and
          Hide
          Carlos Sanchez added a comment -

          and don't have time to test right now

          Show
          Carlos Sanchez added a comment - and don't have time to test right now
          Hide
          Herve Boutemy added a comment - - edited

          Here is a patch to use WriterFactory and XmlStreamWriter added in plexus-utils 1.4.5 to handle stream encoding detection according to the XML content written.

          see http://docs.codehaus.org/display/MAVENUSER/XML+encoding for the roadmap to XML encoding support in Maven2

          Show
          Herve Boutemy added a comment - - edited Here is a patch to use WriterFactory and XmlStreamWriter added in plexus-utils 1.4.5 to handle stream encoding detection according to the XML content written. see http://docs.codehaus.org/display/MAVENUSER/XML+encoding for the roadmap to XML encoding support in Maven2
          Hide
          Brett Porter added a comment -

          can't currently apply as plexus-maven-plugin is not yet released.

          This will likely also require bumping the prerequisites up to maven 2.0.7 to support using a new version of plexus-utils. Applier will need to verify this is the case and adjust if necessary.

          Show
          Brett Porter added a comment - can't currently apply as plexus-maven-plugin is not yet released. This will likely also require bumping the prerequisites up to maven 2.0.7 to support using a new version of plexus-utils. Applier will need to verify this is the case and adjust if necessary.
          Hide
          Herve Boutemy added a comment -

          ok, reworked the patch: the unreleased dependency was a typo (how could I let it into the patch?...)
          but one problem persists when running testcases that I cannot find how to fix:
          org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.artifact.metadata.ArtifactMetadataSource [default] (lookup realm: ClassRealm[plexus.core, parent: null]).

          it contains a little fix for a problem committed this morning in r567988 for MRELEASE-124: String.contains API is only available in Java 5+, it is not in Java 1.4

          Show
          Herve Boutemy added a comment - ok, reworked the patch: the unreleased dependency was a typo (how could I let it into the patch?...) but one problem persists when running testcases that I cannot find how to fix: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.artifact.metadata.ArtifactMetadataSource [default] (lookup realm: ClassRealm [plexus.core, parent: null] ). it contains a little fix for a problem committed this morning in r567988 for MRELEASE-124 : String.contains API is only available in Java 5+, it is not in Java 1.4
          Hide
          Brian Fox added a comment -

          we need to push a release of beta-7 to do a release of 2.0.8. Bumping to next release

          Show
          Brian Fox added a comment - we need to push a release of beta-7 to do a release of 2.0.8. Bumping to next release
          Hide
          Herve Boutemy added a comment -

          everything should be fixed in r591123
          but I didn't find your test (testWritePom in PrepareReleaseMojoTest) to check it

          I think I'll write 2 sets of POM files:

          • src/test/resources/rewrite-for-development/basic-pom-with-encoding
          • src/test/resources/rewrite-for-release/basic-pom-with-encoding
            like basic-pom ones, but with poms in UTF-16: I guarantee it will fail if encoding isn't properly handled somewhere

          but I need some time to understand the coding part of the tests

          any idea on other useful tests?

          Show
          Herve Boutemy added a comment - everything should be fixed in r591123 but I didn't find your test (testWritePom in PrepareReleaseMojoTest) to check it I think I'll write 2 sets of POM files: src/test/resources/rewrite-for-development/basic-pom-with-encoding src/test/resources/rewrite-for-release/basic-pom-with-encoding like basic-pom ones, but with poms in UTF-16: I guarantee it will fail if encoding isn't properly handled somewhere but I need some time to understand the coding part of the tests any idea on other useful tests?
          Hide
          Mark Hobson added a comment -

          The AbstractRewritingReleasePhaseTestCase.testRewriteBasicPomWithEncoding test committed for this issue (r595973) breaks under Windows due to line-endings. This is because AbstractRewritePomsPhase uses native EOL endings whereas the basic-pom-with-encoding expected POM uses LF EOL endings. All other expected POMs use native EOL endings.

          Show
          Mark Hobson added a comment - The AbstractRewritingReleasePhaseTestCase.testRewriteBasicPomWithEncoding test committed for this issue (r595973) breaks under Windows due to line-endings. This is because AbstractRewritePomsPhase uses native EOL endings whereas the basic-pom-with-encoding expected POM uses LF EOL endings. All other expected POMs use native EOL endings.

            People

            • Assignee:
              Herve Boutemy
              Reporter:
              Carlos Sanchez
            • Votes:
              6 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: