Maven
  1. Maven
  2. MNG-4167

version-expression transformation interferes with plugins like GPG

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.0
    • Fix Version/s: 2.2.0
    • Component/s: Plugins and Lifecycle
    • Labels:
      None
    • Complexity:
      Intermediate
    • Number of attachments :
      0

      Description

      See MGPG-14.

        Issue Links

          Activity

          Hide
          John Casey added a comment -

          The problem is that version-expression transformation happens during the install/deploy process, using the ArtifactTransformation interface. Since things like the GPG plugin produce metadata derived from the original file, this transformation renders those derivative files useless.

          Show
          John Casey added a comment - The problem is that version-expression transformation happens during the install/deploy process, using the ArtifactTransformation interface. Since things like the GPG plugin produce metadata derived from the original file, this transformation renders those derivative files useless.
          Show
          John Casey added a comment - see http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions
          Hide
          John Casey added a comment -

          After talking to Brian and Jason more about this issue, it seems better to provide the coordinate-expression transformation up front in the build process, so that any plugin bound to any lifecycle phase will get the same information if they access project.getFile(). The interpolation step is fairly quick, and the transformed version is stored on the filesystem in a temporary file set to delete on exit, to prevent pollution of the project directory. Unfortunately, since the clean plugin deletes everything in the target directory, this temporary file cannot be written there; doing so means the clean plugin would render the build state invalid.

          I've added an integration test to verify that artifact coordinates are replaced properly, in addition to several unit tests to the same effect.

          Show
          John Casey added a comment - After talking to Brian and Jason more about this issue, it seems better to provide the coordinate-expression transformation up front in the build process, so that any plugin bound to any lifecycle phase will get the same information if they access project.getFile(). The interpolation step is fairly quick, and the transformed version is stored on the filesystem in a temporary file set to delete on exit, to prevent pollution of the project directory. Unfortunately, since the clean plugin deletes everything in the target directory, this temporary file cannot be written there; doing so means the clean plugin would render the build state invalid. I've added an integration test to verify that artifact coordinates are replaced properly, in addition to several unit tests to the same effect.
          Hide
          John Casey added a comment -

          transforming the POM coordinates from the get-go causes problems with the release plugin, since the .pom-transformed.xml file doesn't exist in the SCM, and the release plugin needs to rewrite AND THEN COMMIT the POM...if it only has access to the coordinate-transformed version of the POM, then it will commit overwriting the coordinate expressions.

          At the same time, the GPG plugin uses project.getFile() as the source for signing the POM file, instead of using the ProjectArtifactMetadata from project.getArtifact().getMetadata()...so the release plugin and the GPG plugin are directly in conflict here.

          Add to this the clean plugin, which deleted the target directory and won't allow the .pom-transformed.xml file to live there if it's created ahead of the clean plugin execution.

          Finally, the shade plugin uses project.getOriginalModel() when generating the dependency-reduced POM, so any coordinate transformation has to manipulate this object as well.

          Show
          John Casey added a comment - transforming the POM coordinates from the get-go causes problems with the release plugin, since the .pom-transformed.xml file doesn't exist in the SCM, and the release plugin needs to rewrite AND THEN COMMIT the POM...if it only has access to the coordinate-transformed version of the POM, then it will commit overwriting the coordinate expressions. At the same time, the GPG plugin uses project.getFile() as the source for signing the POM file, instead of using the ProjectArtifactMetadata from project.getArtifact().getMetadata()...so the release plugin and the GPG plugin are directly in conflict here. Add to this the clean plugin, which deleted the target directory and won't allow the .pom-transformed.xml file to live there if it's created ahead of the clean plugin execution. Finally, the shade plugin uses project.getOriginalModel() when generating the dependency-reduced POM, so any coordinate transformation has to manipulate this object as well.
          Hide
          John Casey added a comment -

          will revert MNG-3057 and push this to 3.x unless we can come up with something later.

          Show
          John Casey added a comment - will revert MNG-3057 and push this to 3.x unless we can come up with something later.
          Hide
          John Casey added a comment -

          Closing this issue, since the strict case described originally is now fixed for Maven 2.2.0. MNG-4223 carries the wider discussion about POM artifact coordinate expressions now.

          Show
          John Casey added a comment - Closing this issue, since the strict case described originally is now fixed for Maven 2.2.0. MNG-4223 carries the wider discussion about POM artifact coordinate expressions now.

            People

            • Assignee:
              John Casey
              Reporter:
              John Casey
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: