[
https://issues.apache.org/jira/browse/MGPG-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov closed MGPG-42.
------------------------------
Resolution: Auto Closed
This issue has been auto closed because it has been inactive for a long period
of time. If you think this issue still applies, retest your problem with the
most recent version of Maven and the affected component, reopen and post your
results.
> property name references not resolved when copying pom to target directory
> prior to signing
> -------------------------------------------------------------------------------------------
>
> Key: MGPG-42
> URL: https://issues.apache.org/jira/browse/MGPG-42
> Project: Maven 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 was sent by Atlassian JIRA
(v7.6.3#76005)
