You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2013/02/08 18:02:23 UTC
Problem with property substitution into finalName
We have a POM, where the <build> specifies a final name like this:
<finalName>org.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
Re: Problem with property substitution into finalName
Posted by Stephen Connolly <st...@gmail.com>.
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 <msa@schor.com <javascript:;>>
> wrote:
> >
> >> We have a POM, where the <build> specifies a final name like this:
> >>
> >>
> >>
> >>
> <finalName>org.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-unsubscribe@maven.apache.org<javascript:;>
> >> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: users-help@maven.apache.org<javascript:;>
>
>
Re: Problem with property substitution into finalName
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com> wrote:
>
>> We have a POM, where the <build> specifies a final name like this:
>>
>>
>>
>> <finalName>org.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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
Re: Problem with property substitution into finalName
Posted by Marshall Schor <ms...@schor.com>.
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 <ms...@schor.com> wrote:
>
>> We have a POM, where the <build> specifies a final name like this:
>>
>>
>>
>> <finalName>org.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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Problem with property substitution into finalName
Posted by Stephen Connolly <st...@gmail.com>.
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 <ms...@schor.com> wrote:
> We have a POM, where the <build> specifies a final name like this:
>
>
>
> <finalName>org.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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Problem with property substitution into finalName
Posted by Stephen Connolly <st...@gmail.com>.
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 <ms...@schor.com> wrote:
> We have a POM, where the <build> specifies a final name like this:
>
>
>
> <finalName>org.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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>