Problem with property substitution into finalName
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates jars
using the substituted value, e.g. org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as
the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
Thanks Stephen,
I'm trying to figure out why I'm not seeing this in the actual staged artifacts,
or in previous releases.
Here's what I've concluded:
The maven-gpg-plugin has a bug - it copies the pom.xml to the finalname.pom, in
target, and then signs that, without substituting into the property variable in
the finalname. So, if you look into /target, it's got the wrong name.
But, when the install plugin installs, it
(a) ignores the incorrectly named ...pom in the /target, and instead, copies
the original pom to the install spot. You can see that in the run output for
the install step:
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\pom.xml to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\
uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom
(b) it does copy the incorrectly named .asc file to the repository, but
(SURPRISE !) it fixes up the name in the target :-) :
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\target\org.apache.uima.textmarker.engine_${parsedVersion
.osgiVersion}.pom.asc to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom.asc
So, we're only seeing this issue due to the fact that we happened to look into
the /target directory.
-Marshall
On 2/8/2013 12:33 PM, Stephen Connolly wrote:
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same as
the
version, except with a period before the SNAPSHOT qualifier, for example.
This works fine for plugins like the maven-jar-plugin - it nicely creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier steps
(like the maven-jar-plugin) use this and have the correct string (with the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Problem with property substitution into finalName
On Friday, 8 February 2013, Marshall Schor wrote:
Thanks Stephen,
I'm trying to figure out why I'm not seeing this in the actual staged
artifacts,
or in previous releases.
Here's what I've concluded:
The maven-gpg-plugin has a bug - it copies the pom.xml to the
finalname.pom, in
target, and then signs that, without substituting into the property
variable in
the finalname. So, if you look into /target, it's got the wrong name.
But, when the install plugin installs, it
(a) ignores the incorrectly named ...pom in the /target, and instead,
copies
the original pom to the install spot. You can see that in the run output
for
the install step:
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\pom.xml
to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\
uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom
(b) it does copy the incorrectly named .asc file to the repository, but
(SURPRISE !) it fixes up the name in the target :-) :
The act of deploying standardises the names to the repository format. In a
sense finalName is an irrelevant distraction from Maven's point of view.
All it cares about is getting the artifact into the remote repository with
a name corresponding to the GAVCT coordinates
As a user, though, some people don't like renaming the file on disk in
their target dir, so for these people finalName is useful.
Still it would be best if the gpg plugin at least respected the user
somewhat.
So not a blocking bug, more an annoying one, at least by the sound of it.
[INFO] Installing
C:\au\t\tm-rc4\src-to-build\textmarker-2.0.0\textmarker-ep-engine\target\org.apache.uima.textmarker.engine_${parsedVersion
.osgiVersion}.pom.asc to
C:\Users\IBM_ADMIN\.m2\repository\org\apache\uima\textmarker-ep-engine\2.0.0\textmarker-ep-engine-2.0.0.pom.asc
So, we're only seeing this issue due to the fact that we happened to look
into
the /target directory.
-Marshall
On 2/8/2013 12:33 PM, Stephen Connolly wrote:
Please read this:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
You will conclude that the only solution is to make the finalName a
configuration parameter of the mojo so that the recursive property
evaluation code can compute the effective final value on injection of the
final configuration before invoking the mojo.
An alternative solution would be to make the mojo pass the
project.getBuild.getFinalName() through the property interpolator before
use.
Sounds like a bug. A patch with tests would be good. Ping me if you write
one and I'll apply the patch (if it looks good) and run a release.
Alternatively, you could ask any of the people in the Committer School (
http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html
)
if they would like to take this as a task (ok we only have one person in
the committer school: Chris Graham, but don't let that stop you, we've
had
a 50% graduation rate so far)
-Stephen
On 8 February 2013 17:02, Marshall Schor m...@schor.com javascript:;
wrote:
We have a POM, where the build specifies a final name like this:
finalNameorg.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}/finalName
We use the maven-build-helper plugin to set the variable to be the same
as
the
version, except with a period before the SNAPSHOT qualifier, for
example.
This works fine for plugins like the maven-jar-plugin - it nicely
creates
jars
using the substituted value, e.g.
org.apache.uima.textmarker.engine_2.0.0.jar
However, the maven-gpg-plugin, when copying the project's pom.xml file
to the
target/ to sign it, copies it to a file named like this:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + .pom );
FileUtils.copyFile( project.getFile(), pomToSign )
The code fragment: project.getBuild().getFinalName() must be getting the
un-substituted/original version of the the finalName property, because
we
see
the pom is copied into the target/ as
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
We know the property is being properly defined, etc., because earlier
steps
(like the maven-jar-plugin) use this and have the correct string (with
the
substituted value).
How can we fix this?
-Marshall Schor
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:;
For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:;
For additional commands, e-mail: users-h...@maven.apache.orgjavascript:;
