Marshall Schor created MGPG-42:
----------------------------------

             Summary: property name references not resolved when copying pom to 
target directory prior to signing
                 Key: MGPG-42
                 URL: https://jira.codehaus.org/browse/MGPG-42
             Project: Maven 2.x and 3.x GPG Plugin
          Issue Type: Bug
    Affects Versions: 1.4
            Reporter: Marshall Schor
            Priority: Minor


We sometimes configure our <build> with a <finalName> which has a string where 
the "version" part is a maven dynamically-set property.  We do this so that 
Jars we build that are Eclipse plugins can follow the Eclipse conventions of 
using periods (e.g., in front of SNAPSHOT, rather than the maven convention of 
a dash).  We use the build-helper-maven-plugin parse-version goal to do this.

The maven-jar-plugin takes the finalName string and manages to substitute the 
value that the build-helper-maven-plugin sets.

The gpg plugin copies the projects pom.xml file to the target before signing 
it.  It uses this bit of code:

    File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + ".pom" );
    FileUtils.copyFile( project.getFile(), pomToSign )

Unfortunately, the ...getFinalName() picks up the final name string without 
substituting the value of the variable, so looking in the target directory, we 
see things like:

org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom 

and

org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom.asc

This should be fixed to operate like the maven-jar-plugin works, with the 
finalName value being processed to replace variables with their values.

Now, this may not be urgent.  Here's why.  When a subsequent Maven Install 
runs, it puts the pom and signature into the repository.  But to my surprise, 
it copies the pom not from the target, but it does get the signature from the 
target, and RENAMES it (surprise!) so in the repository, things look ok.

But anyone who works with signed files in the target directory would get the 
wrong names (if dynamically set variables are used as part of the name), so 
this should probably be fixed.
   

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to