version-expression transformation interferes with plugins like GPG

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.

see http://docs.codehaus.org/display/MAVEN/Transforming+POM+Version+Expressions

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.

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.

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

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.