Maven 2 & 3

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

This issue relates to:
MNG-4223 Resolve expressions in POM artifact coordinates Major Open
MNG-3057 properties not expanded in generated POMs when building A/B/C nested projects Major Closed
This issue is related to:
MGPG-14 With maven 2.1.0 some poms end up with invalid signatures Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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.
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.