You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Henrik Østerlund Gram <he...@gmail.com> on 2014/03/23 22:36:15 UTC
properties that are not being resolved
I stumbled over some rather strange behaviour regarding properties. It
seems properties generated by one plugin are not always resolved for other
plugins and I can't figure out why.
I use a plugin to make info about the git branch available in the
properties so it can be passed to other plugins. The particular plugin
does not seem important, but I've included it here for sake of completeness:
<plugin>
<groupId>com.code54.mojo</groupId>
<artifactId>buildversion-plugin</artifactId>
<version>1.0.3</version>
<configuration>
<tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
</configuration>
<executions>
<execution>
<goals>
<goal>set-properties</goal>
</goals>
</execution>
</executions>
</plugin>
But when I referenced the properties set by the plugin in an env entry for
the maven ear plugin, the properties were not resolved at all:
<envEntries>
<env-entry>
<description>Middleware build information</description>
<env-entry-name>java:app/env/sw-version</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>${build-commit} @ ${build-tstamp} built on
${maven.build.timestamp}</env-entry-value>
</env-entry>
</envEntries>
Just to be sure, I used the latest maven and tried both version 2.9 of the
plugin and the latest from the repo with the same result.
The only way I managed to fix this was to patch the maven-ear-plugin
itself, adding the following code in GenerateApplicationXmlMojo.execute():
// Fix env variable substitutions
Properties props = project.getProperties();
PlexusConfiguration[] entries = envEntries.getChildren();
if (entries != null) {
for (PlexusConfiguration entry : entries) {
if ("env-entry".equals(entry.getName())) {
PlexusConfiguration[] envEntryChildren = entry.getChildren();
if (envEntryChildren != null) {
for (PlexusConfiguration envEntryChild : envEntryChildren) {
envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
props));
}
}
}
}
}
Then it worked just fine, but I don't understand why this is necessary. I
thought whatever called the plugin was supposed to have done the variable
substitution already. So clearly the properties were present at the time
of executing the plugin, but they werent being automaticly substituted.
To add to the confusion, using ${project.version} in the env-entry-value
was resolved just fine, but just not the properties coming from another
plugin despite the plugins being run in the correct order.
To further add to the confusion, I then used maven ant-run plugin, echoing
the values of properties which worked just fine (!)
While I solved the problem for me by making a locally patched version of
the ear plugin, it's not really a solution I favour, so I hope someone can
provide a better and more permanent fix.
Regards,
Henrik Gram
Re: properties that are not being resolved
Posted by Stephen Connolly <st...@gmail.com>.
The File vs String types note is the relevant part IIRC... It's not just
file vs string though
On Tuesday, 25 March 2014, Henrik Østerlund Gram <he...@gmail.com>
wrote:
> Thanks for the link. It was quite informative, but I'm again a little
> confused because it is stated in your explanation,
> the <configuration> sections will have mojo-injected properties evaluated,
> but that isn't the case in my example. I was trying to have such
> properties evaluated in a <envEntries> element inside a <configuration>
> element for the ear plugin, but it would not work until I modified the
> plugin to do an extra substitution itself.
>
> Regards,
> Henrik Gram
>
> On Mon, Mar 24, 2014 at 10:38 PM, Stephen Connolly <
> stephen.alan.connolly@gmail.com> wrote:
>
> > Please read my answer to a similar question on Stack Overflow:
> >
> >
> http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
> >
> >
> > On 23 March 2014 21:36, Henrik Østerlund Gram <he...@gmail.com>
> > wrote:
> >
> > > I stumbled over some rather strange behaviour regarding properties. It
> > > seems properties generated by one plugin are not always resolved for
> > other
> > > plugins and I can't figure out why.
> > >
> > > I use a plugin to make info about the git branch available in the
> > > properties so it can be passed to other plugins. The particular plugin
> > > does not seem important, but I've included it here for sake of
> > > completeness:
> > >
> > > <plugin>
> > > <groupId>com.code54.mojo</groupId>
> > > <artifactId>buildversion-plugin</artifactId>
> > > <version>1.0.3</version>
> > > <configuration>
> > > <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> > > </configuration>
> > > <executions>
> > > <execution>
> > > <goals>
> > > <goal>set-properties</goal>
> > > </goals>
> > > </execution>
> > > </executions>
> > > </plugin>
> > >
> > > But when I referenced the properties set by the plugin in an env entry
> > for
> > > the maven ear plugin, the properties were not resolved at all:
> > >
> > > <envEntries>
> > > <env-entry>
> > > <description>Middleware build information</description>
> > > <env-entry-name>java:app/env/sw-version</env-entry-name>
> > > <env-entry-type>java.lang.String</env-entry-type>
> > > <env-entry-value>${build-commit} @ ${build-tstamp} built on
> > > ${maven.build.timestamp}</env-entry-value>
> > > </env-entry>
> > > </envEntries>
> > >
> > > Just to be sure, I used the latest maven and tried both version 2.9 of
> > the
> > > plugin and the latest from the repo with the same result.
> > >
> > > The only way I managed to fix this was to patch the maven-ear-plugin
> > > itself, adding the following code in
> > GenerateApplicationXmlMojo.execute():
> > >
> > > // Fix env variable substitutions
> > > Properties props = project.getProperties();
> > > PlexusConfiguration[] entries = envEntries.getChildren();
> > > if (entries != null) {
> > > for (PlexusConfiguration entry : entries) {
> > > if ("env-entry".equals(entry.getName())) {
> > > PlexusConfiguration[] envEntryChildren =
> entry.getChildren();
> > > if (envEntryChildren != null) {
> > > for (PlexusConfiguration envEntryChild :
> > envEntryChildren)
> > > {
> > >
> > > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > > props));
> > > }
> > > }
> > > }
> > > }
> > > }
> > >
> > > Then it worked just fine, but I don't understand why this is necessary.
> > I
> > > thought whatever called the plugin was supposed to have done the
> variable
> > > substitution already. So clearly the properties were present at the
> time
> > > of executing the plugin, but they werent being automaticly substituted.
> > >
> > > To add to the confusion, using ${project.version} in the
> env-entry-value
> > > was resolved just fine, but just not the properties coming from another
> > > plugin despite the plugins being run in the correct order.
> > >
> > > To further add to th
--
Sent from my phone
Re: properties that are not being resolved
Posted by Henrik Østerlund Gram <he...@gmail.com>.
Thanks for the link. It was quite informative, but I'm again a little
confused because it is stated in your explanation,
the <configuration> sections will have mojo-injected properties evaluated,
but that isn't the case in my example. I was trying to have such
properties evaluated in a <envEntries> element inside a <configuration>
element for the ear plugin, but it would not work until I modified the
plugin to do an extra substitution itself.
Regards,
Henrik Gram
On Mon, Mar 24, 2014 at 10:38 PM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:
> Please read my answer to a similar question on Stack Overflow:
>
> http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
>
>
> On 23 March 2014 21:36, Henrik Østerlund Gram <he...@gmail.com>
> wrote:
>
> > I stumbled over some rather strange behaviour regarding properties. It
> > seems properties generated by one plugin are not always resolved for
> other
> > plugins and I can't figure out why.
> >
> > I use a plugin to make info about the git branch available in the
> > properties so it can be passed to other plugins. The particular plugin
> > does not seem important, but I've included it here for sake of
> > completeness:
> >
> > <plugin>
> > <groupId>com.code54.mojo</groupId>
> > <artifactId>buildversion-plugin</artifactId>
> > <version>1.0.3</version>
> > <configuration>
> > <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> > </configuration>
> > <executions>
> > <execution>
> > <goals>
> > <goal>set-properties</goal>
> > </goals>
> > </execution>
> > </executions>
> > </plugin>
> >
> > But when I referenced the properties set by the plugin in an env entry
> for
> > the maven ear plugin, the properties were not resolved at all:
> >
> > <envEntries>
> > <env-entry>
> > <description>Middleware build information</description>
> > <env-entry-name>java:app/env/sw-version</env-entry-name>
> > <env-entry-type>java.lang.String</env-entry-type>
> > <env-entry-value>${build-commit} @ ${build-tstamp} built on
> > ${maven.build.timestamp}</env-entry-value>
> > </env-entry>
> > </envEntries>
> >
> > Just to be sure, I used the latest maven and tried both version 2.9 of
> the
> > plugin and the latest from the repo with the same result.
> >
> > The only way I managed to fix this was to patch the maven-ear-plugin
> > itself, adding the following code in
> GenerateApplicationXmlMojo.execute():
> >
> > // Fix env variable substitutions
> > Properties props = project.getProperties();
> > PlexusConfiguration[] entries = envEntries.getChildren();
> > if (entries != null) {
> > for (PlexusConfiguration entry : entries) {
> > if ("env-entry".equals(entry.getName())) {
> > PlexusConfiguration[] envEntryChildren = entry.getChildren();
> > if (envEntryChildren != null) {
> > for (PlexusConfiguration envEntryChild :
> envEntryChildren)
> > {
> >
> > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > props));
> > }
> > }
> > }
> > }
> > }
> >
> > Then it worked just fine, but I don't understand why this is necessary.
> I
> > thought whatever called the plugin was supposed to have done the variable
> > substitution already. So clearly the properties were present at the time
> > of executing the plugin, but they werent being automaticly substituted.
> >
> > To add to the confusion, using ${project.version} in the env-entry-value
> > was resolved just fine, but just not the properties coming from another
> > plugin despite the plugins being run in the correct order.
> >
> > To further add to the confusion, I then used maven ant-run plugin,
> echoing
> > the values of properties which worked just fine (!)
> >
> > While I solved the problem for me by making a locally patched version of
> > the ear plugin, it's not really a solution I favour, so I hope someone
> can
> > provide a better and more permanent fix.
> >
> > Regards,
> > Henrik Gram
> >
>
Re: properties that are not being resolved
Posted by Stephen Connolly <st...@gmail.com>.
Please read my answer to a similar question on Stack Overflow:
http://stackoverflow.com/questions/14725197/reading-properties-file-from-pom-file-in-maven/14727072#14727072
On 23 March 2014 21:36, Henrik Østerlund Gram <he...@gmail.com> wrote:
> I stumbled over some rather strange behaviour regarding properties. It
> seems properties generated by one plugin are not always resolved for other
> plugins and I can't figure out why.
>
> I use a plugin to make info about the git branch available in the
> properties so it can be passed to other plugins. The particular plugin
> does not seem important, but I've included it here for sake of
> completeness:
>
> <plugin>
> <groupId>com.code54.mojo</groupId>
> <artifactId>buildversion-plugin</artifactId>
> <version>1.0.3</version>
> <configuration>
> <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> </configuration>
> <executions>
> <execution>
> <goals>
> <goal>set-properties</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> But when I referenced the properties set by the plugin in an env entry for
> the maven ear plugin, the properties were not resolved at all:
>
> <envEntries>
> <env-entry>
> <description>Middleware build information</description>
> <env-entry-name>java:app/env/sw-version</env-entry-name>
> <env-entry-type>java.lang.String</env-entry-type>
> <env-entry-value>${build-commit} @ ${build-tstamp} built on
> ${maven.build.timestamp}</env-entry-value>
> </env-entry>
> </envEntries>
>
> Just to be sure, I used the latest maven and tried both version 2.9 of the
> plugin and the latest from the repo with the same result.
>
> The only way I managed to fix this was to patch the maven-ear-plugin
> itself, adding the following code in GenerateApplicationXmlMojo.execute():
>
> // Fix env variable substitutions
> Properties props = project.getProperties();
> PlexusConfiguration[] entries = envEntries.getChildren();
> if (entries != null) {
> for (PlexusConfiguration entry : entries) {
> if ("env-entry".equals(entry.getName())) {
> PlexusConfiguration[] envEntryChildren = entry.getChildren();
> if (envEntryChildren != null) {
> for (PlexusConfiguration envEntryChild : envEntryChildren)
> {
>
> envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> props));
> }
> }
> }
> }
> }
>
> Then it worked just fine, but I don't understand why this is necessary. I
> thought whatever called the plugin was supposed to have done the variable
> substitution already. So clearly the properties were present at the time
> of executing the plugin, but they werent being automaticly substituted.
>
> To add to the confusion, using ${project.version} in the env-entry-value
> was resolved just fine, but just not the properties coming from another
> plugin despite the plugins being run in the correct order.
>
> To further add to the confusion, I then used maven ant-run plugin, echoing
> the values of properties which worked just fine (!)
>
> While I solved the problem for me by making a locally patched version of
> the ear plugin, it's not really a solution I favour, so I hope someone can
> provide a better and more permanent fix.
>
> Regards,
> Henrik Gram
>
Re: properties that are not being resolved
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
> Hi Henrik,
>
> FYI, my projects use buildnumber-maven-plugin with git and it works great.
> Probably the docs are just out of date.
That looks like. I have created the following JIRA ticket for this.
https://jira.codehaus.org/browse/MBUILDNUM-119
If you have supplementals/infos etc. don't hesitate to add those
information to the ticket...may be a good idea how to write the information.
Kind regards
Karl-Heinz Marbaise
>
> Regards,
> Curtis
> On Mar 24, 2014 3:05 AM, "Henrik Østerlund Gram" <he...@gmail.com>
> wrote:
>
>> The one at
>> http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
>> states in the first couple of lines that it only works with subversion and
>> I'm using git.
>>
>> Aside from that, I can't really see why it would make a difference; how
>> many ways are there to set properties? I did establish that the properties
>> are indeed set as I can print them via the ant-run plugin and via the a
>> modified ear-plugin.
>>
>>
>>
>> On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus <bm...@batmat.net>
>> wrote:
>>
>>> Hi,
>>> Out of curiosity, why don't you use the seemingly equivalent mojo
>>> buildnumber maven plugin? May not be your issue, but may be the plugin
>>> you're using doesn't create properties in the right way (no offense, just
>>> trying to guess)?
>>> My 2 cents
>>> Le 23 mars 2014 22:37, "Henrik Østerlund Gram" <he...@gmail.com> a
>>> écrit :
>>>
>>>> I stumbled over some rather strange behaviour regarding properties. It
>>>> seems properties generated by one plugin are not always resolved for
>>> other
>>>> plugins and I can't figure out why.
>>>>
>>>> I use a plugin to make info about the git branch available in the
>>>> properties so it can be passed to other plugins. The particular plugin
>>>> does not seem important, but I've included it here for sake of
>>>> completeness:
>>>>
>>>> <plugin>
>>>> <groupId>com.code54.mojo</groupId>
>>>> <artifactId>buildversion-plugin</artifactId>
>>>> <version>1.0.3</version>
>>>> <configuration>
>>>> <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
>>>> </configuration>
>>>> <executions>
>>>> <execution>
>>>> <goals>
>>>> <goal>set-properties</goal>
>>>> </goals>
>>>> </execution>
>>>> </executions>
>>>> </plugin>
>>>>
>>>> But when I referenced the properties set by the plugin in an env entry
>>> for
>>>> the maven ear plugin, the properties were not resolved at all:
>>>>
>>>> <envEntries>
>>>> <env-entry>
>>>> <description>Middleware build information</description>
>>>> <env-entry-name>java:app/env/sw-version</env-entry-name>
>>>> <env-entry-type>java.lang.String</env-entry-type>
>>>> <env-entry-value>${build-commit} @ ${build-tstamp} built on
>>>> ${maven.build.timestamp}</env-entry-value>
>>>> </env-entry>
>>>> </envEntries>
>>>>
>>>> Just to be sure, I used the latest maven and tried both version 2.9 of
>>> the
>>>> plugin and the latest from the repo with the same result.
>>>>
>>>> The only way I managed to fix this was to patch the maven-ear-plugin
>>>> itself, adding the following code in
>>> GenerateApplicationXmlMojo.execute():
>>>>
>>>> // Fix env variable substitutions
>>>> Properties props = project.getProperties();
>>>> PlexusConfiguration[] entries = envEntries.getChildren();
>>>> if (entries != null) {
>>>> for (PlexusConfiguration entry : entries) {
>>>> if ("env-entry".equals(entry.getName())) {
>>>> PlexusConfiguration[] envEntryChildren =
>> entry.getChildren();
>>>> if (envEntryChildren != null) {
>>>> for (PlexusConfiguration envEntryChild :
>>> envEntryChildren)
>>>> {
>>>>
>>>> envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
>>>> props));
>>>> }
>>>> }
>>>> }
>>>> }
>>>> }
>>>>
>>>> Then it worked just fine, but I don't understand why this is necessary.
>>> I
>>>> thought whatever called the plugin was supposed to have done the
>> variable
>>>> substitution already. So clearly the properties were present at the
>> time
>>>> of executing the plugin, but they werent being automaticly substituted.
>>>>
>>>> To add to the confusion, using ${project.version} in the
>> env-entry-value
>>>> was resolved just fine, but just not the properties coming from another
>>>> plugin despite the plugins being run in the correct order.
>>>>
>>>> To further add to the confusion, I then used maven ant-run plugin,
>>> echoing
>>>> the values of properties which worked just fine (!)
>>>>
>>>> While I solved the problem for me by making a locally patched version
>> of
>>>> the ear plugin, it's not really a solution I favour, so I hope someone
>>> can
>>>> provide a better and more permanent fix.
>>>>
>>>> Regards,
>>>> Henrik Gram
>>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: properties that are not being resolved
Posted by Curtis Rueden <ct...@wisc.edu>.
Hi Henrik,
FYI, my projects use buildnumber-maven-plugin with git and it works great.
Probably the docs are just out of date.
Regards,
Curtis
On Mar 24, 2014 3:05 AM, "Henrik Østerlund Gram" <he...@gmail.com>
wrote:
> The one at
> http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
> states in the first couple of lines that it only works with subversion and
> I'm using git.
>
> Aside from that, I can't really see why it would make a difference; how
> many ways are there to set properties? I did establish that the properties
> are indeed set as I can print them via the ant-run plugin and via the a
> modified ear-plugin.
>
>
>
> On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus <bm...@batmat.net>
> wrote:
>
> > Hi,
> > Out of curiosity, why don't you use the seemingly equivalent mojo
> > buildnumber maven plugin? May not be your issue, but may be the plugin
> > you're using doesn't create properties in the right way (no offense, just
> > trying to guess)?
> > My 2 cents
> > Le 23 mars 2014 22:37, "Henrik Østerlund Gram" <he...@gmail.com> a
> > écrit :
> >
> > > I stumbled over some rather strange behaviour regarding properties. It
> > > seems properties generated by one plugin are not always resolved for
> > other
> > > plugins and I can't figure out why.
> > >
> > > I use a plugin to make info about the git branch available in the
> > > properties so it can be passed to other plugins. The particular plugin
> > > does not seem important, but I've included it here for sake of
> > > completeness:
> > >
> > > <plugin>
> > > <groupId>com.code54.mojo</groupId>
> > > <artifactId>buildversion-plugin</artifactId>
> > > <version>1.0.3</version>
> > > <configuration>
> > > <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> > > </configuration>
> > > <executions>
> > > <execution>
> > > <goals>
> > > <goal>set-properties</goal>
> > > </goals>
> > > </execution>
> > > </executions>
> > > </plugin>
> > >
> > > But when I referenced the properties set by the plugin in an env entry
> > for
> > > the maven ear plugin, the properties were not resolved at all:
> > >
> > > <envEntries>
> > > <env-entry>
> > > <description>Middleware build information</description>
> > > <env-entry-name>java:app/env/sw-version</env-entry-name>
> > > <env-entry-type>java.lang.String</env-entry-type>
> > > <env-entry-value>${build-commit} @ ${build-tstamp} built on
> > > ${maven.build.timestamp}</env-entry-value>
> > > </env-entry>
> > > </envEntries>
> > >
> > > Just to be sure, I used the latest maven and tried both version 2.9 of
> > the
> > > plugin and the latest from the repo with the same result.
> > >
> > > The only way I managed to fix this was to patch the maven-ear-plugin
> > > itself, adding the following code in
> > GenerateApplicationXmlMojo.execute():
> > >
> > > // Fix env variable substitutions
> > > Properties props = project.getProperties();
> > > PlexusConfiguration[] entries = envEntries.getChildren();
> > > if (entries != null) {
> > > for (PlexusConfiguration entry : entries) {
> > > if ("env-entry".equals(entry.getName())) {
> > > PlexusConfiguration[] envEntryChildren =
> entry.getChildren();
> > > if (envEntryChildren != null) {
> > > for (PlexusConfiguration envEntryChild :
> > envEntryChildren)
> > > {
> > >
> > > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > > props));
> > > }
> > > }
> > > }
> > > }
> > > }
> > >
> > > Then it worked just fine, but I don't understand why this is necessary.
> > I
> > > thought whatever called the plugin was supposed to have done the
> variable
> > > substitution already. So clearly the properties were present at the
> time
> > > of executing the plugin, but they werent being automaticly substituted.
> > >
> > > To add to the confusion, using ${project.version} in the
> env-entry-value
> > > was resolved just fine, but just not the properties coming from another
> > > plugin despite the plugins being run in the correct order.
> > >
> > > To further add to the confusion, I then used maven ant-run plugin,
> > echoing
> > > the values of properties which worked just fine (!)
> > >
> > > While I solved the problem for me by making a locally patched version
> of
> > > the ear plugin, it's not really a solution I favour, so I hope someone
> > can
> > > provide a better and more permanent fix.
> > >
> > > Regards,
> > > Henrik Gram
> > >
> >
>
Re: properties that are not being resolved
Posted by Henrik Østerlund Gram <he...@gmail.com>.
Ok, I see.
Any chance of such a change making it into the official ear-plugin? I
think it would be generally useful to be able to reference properties in
the env-entry values. Could post a pull request if desired, but judging by
the months old ones at https://github.com/apache/maven-plugins/pulls it
doesn't appear those are being processed by anyone. Is there another way
to suggest that change be implemented?
Regards,
Henrik Gram
On Mon, Mar 24, 2014 at 9:13 AM, Anders Hammar <an...@hammar.net> wrote:
> It doesn't matter which plugin you use to set the property. What does
> matter is when the property substitution takes place. It normally happens
> in the very beginning of the Maven build when the pom is read, before the
> build lifecycle is executed and way before your plugin is executed. So you
> need the plugin (where you use the created property) to do an "extra"
> property substition step as you describe in your code.
>
> /Anders
>
>
> On Mon, Mar 24, 2014 at 9:04 AM, Henrik Østerlund Gram <
> henrik.gram@gmail.com> wrote:
>
> > The one at
> > http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
> > states in the first couple of lines that it only works with subversion
> and
> > I'm using git.
> >
> > Aside from that, I can't really see why it would make a difference; how
> > many ways are there to set properties? I did establish that the
> properties
> > are indeed set as I can print them via the ant-run plugin and via the a
> > modified ear-plugin.
> >
> >
> >
> > On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus <bm...@batmat.net>
> > wrote:
> >
> > > Hi,
> > > Out of curiosity, why don't you use the seemingly equivalent mojo
> > > buildnumber maven plugin? May not be your issue, but may be the plugin
> > > you're using doesn't create properties in the right way (no offense,
> just
> > > trying to guess)?
> > > My 2 cents
> > > Le 23 mars 2014 22:37, "Henrik Østerlund Gram" <he...@gmail.com>
> a
> > > écrit :
> > >
> > > > I stumbled over some rather strange behaviour regarding properties.
> It
> > > > seems properties generated by one plugin are not always resolved for
> > > other
> > > > plugins and I can't figure out why.
> > > >
> > > > I use a plugin to make info about the git branch available in the
> > > > properties so it can be passed to other plugins. The particular
> plugin
> > > > does not seem important, but I've included it here for sake of
> > > > completeness:
> > > >
> > > > <plugin>
> > > > <groupId>com.code54.mojo</groupId>
> > > > <artifactId>buildversion-plugin</artifactId>
> > > > <version>1.0.3</version>
> > > > <configuration>
> > > > <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> > > > </configuration>
> > > > <executions>
> > > > <execution>
> > > > <goals>
> > > > <goal>set-properties</goal>
> > > > </goals>
> > > > </execution>
> > > > </executions>
> > > > </plugin>
> > > >
> > > > But when I referenced the properties set by the plugin in an env
> entry
> > > for
> > > > the maven ear plugin, the properties were not resolved at all:
> > > >
> > > > <envEntries>
> > > > <env-entry>
> > > > <description>Middleware build information</description>
> > > > <env-entry-name>java:app/env/sw-version</env-entry-name>
> > > > <env-entry-type>java.lang.String</env-entry-type>
> > > > <env-entry-value>${build-commit} @ ${build-tstamp} built on
> > > > ${maven.build.timestamp}</env-entry-value>
> > > > </env-entry>
> > > > </envEntries>
> > > >
> > > > Just to be sure, I used the latest maven and tried both version 2.9
> of
> > > the
> > > > plugin and the latest from the repo with the same result.
> > > >
> > > > The only way I managed to fix this was to patch the maven-ear-plugin
> > > > itself, adding the following code in
> > > GenerateApplicationXmlMojo.execute():
> > > >
> > > > // Fix env variable substitutions
> > > > Properties props = project.getProperties();
> > > > PlexusConfiguration[] entries = envEntries.getChildren();
> > > > if (entries != null) {
> > > > for (PlexusConfiguration entry : entries) {
> > > > if ("env-entry".equals(entry.getName())) {
> > > > PlexusConfiguration[] envEntryChildren =
> > entry.getChildren();
> > > > if (envEntryChildren != null) {
> > > > for (PlexusConfiguration envEntryChild :
> > > envEntryChildren)
> > > > {
> > > >
> > > >
> envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > > > props));
> > > > }
> > > > }
> > > > }
> > > > }
> > > > }
> > > >
> > > > Then it worked just fine, but I don't understand why this is
> necessary.
> > > I
> > > > thought whatever called the plugin was supposed to have done the
> > variable
> > > > substitution already. So clearly the properties were present at the
> > time
> > > > of executing the plugin, but they werent being automaticly
> substituted.
> > > >
> > > > To add to the confusion, using ${project.version} in the
> > env-entry-value
> > > > was resolved just fine, but just not the properties coming from
> another
> > > > plugin despite the plugins being run in the correct order.
> > > >
> > > > To further add to the confusion, I then used maven ant-run plugin,
> > > echoing
> > > > the values of properties which worked just fine (!)
> > > >
> > > > While I solved the problem for me by making a locally patched version
> > of
> > > > the ear plugin, it's not really a solution I favour, so I hope
> someone
> > > can
> > > > provide a better and more permanent fix.
> > > >
> > > > Regards,
> > > > Henrik Gram
> > > >
> > >
> >
>
Re: properties that are not being resolved
Posted by Anders Hammar <an...@hammar.net>.
It doesn't matter which plugin you use to set the property. What does
matter is when the property substitution takes place. It normally happens
in the very beginning of the Maven build when the pom is read, before the
build lifecycle is executed and way before your plugin is executed. So you
need the plugin (where you use the created property) to do an "extra"
property substition step as you describe in your code.
/Anders
On Mon, Mar 24, 2014 at 9:04 AM, Henrik Østerlund Gram <
henrik.gram@gmail.com> wrote:
> The one at
> http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
> states in the first couple of lines that it only works with subversion and
> I'm using git.
>
> Aside from that, I can't really see why it would make a difference; how
> many ways are there to set properties? I did establish that the properties
> are indeed set as I can print them via the ant-run plugin and via the a
> modified ear-plugin.
>
>
>
> On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus <bm...@batmat.net>
> wrote:
>
> > Hi,
> > Out of curiosity, why don't you use the seemingly equivalent mojo
> > buildnumber maven plugin? May not be your issue, but may be the plugin
> > you're using doesn't create properties in the right way (no offense, just
> > trying to guess)?
> > My 2 cents
> > Le 23 mars 2014 22:37, "Henrik Østerlund Gram" <he...@gmail.com> a
> > écrit :
> >
> > > I stumbled over some rather strange behaviour regarding properties. It
> > > seems properties generated by one plugin are not always resolved for
> > other
> > > plugins and I can't figure out why.
> > >
> > > I use a plugin to make info about the git branch available in the
> > > properties so it can be passed to other plugins. The particular plugin
> > > does not seem important, but I've included it here for sake of
> > > completeness:
> > >
> > > <plugin>
> > > <groupId>com.code54.mojo</groupId>
> > > <artifactId>buildversion-plugin</artifactId>
> > > <version>1.0.3</version>
> > > <configuration>
> > > <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> > > </configuration>
> > > <executions>
> > > <execution>
> > > <goals>
> > > <goal>set-properties</goal>
> > > </goals>
> > > </execution>
> > > </executions>
> > > </plugin>
> > >
> > > But when I referenced the properties set by the plugin in an env entry
> > for
> > > the maven ear plugin, the properties were not resolved at all:
> > >
> > > <envEntries>
> > > <env-entry>
> > > <description>Middleware build information</description>
> > > <env-entry-name>java:app/env/sw-version</env-entry-name>
> > > <env-entry-type>java.lang.String</env-entry-type>
> > > <env-entry-value>${build-commit} @ ${build-tstamp} built on
> > > ${maven.build.timestamp}</env-entry-value>
> > > </env-entry>
> > > </envEntries>
> > >
> > > Just to be sure, I used the latest maven and tried both version 2.9 of
> > the
> > > plugin and the latest from the repo with the same result.
> > >
> > > The only way I managed to fix this was to patch the maven-ear-plugin
> > > itself, adding the following code in
> > GenerateApplicationXmlMojo.execute():
> > >
> > > // Fix env variable substitutions
> > > Properties props = project.getProperties();
> > > PlexusConfiguration[] entries = envEntries.getChildren();
> > > if (entries != null) {
> > > for (PlexusConfiguration entry : entries) {
> > > if ("env-entry".equals(entry.getName())) {
> > > PlexusConfiguration[] envEntryChildren =
> entry.getChildren();
> > > if (envEntryChildren != null) {
> > > for (PlexusConfiguration envEntryChild :
> > envEntryChildren)
> > > {
> > >
> > > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > > props));
> > > }
> > > }
> > > }
> > > }
> > > }
> > >
> > > Then it worked just fine, but I don't understand why this is necessary.
> > I
> > > thought whatever called the plugin was supposed to have done the
> variable
> > > substitution already. So clearly the properties were present at the
> time
> > > of executing the plugin, but they werent being automaticly substituted.
> > >
> > > To add to the confusion, using ${project.version} in the
> env-entry-value
> > > was resolved just fine, but just not the properties coming from another
> > > plugin despite the plugins being run in the correct order.
> > >
> > > To further add to the confusion, I then used maven ant-run plugin,
> > echoing
> > > the values of properties which worked just fine (!)
> > >
> > > While I solved the problem for me by making a locally patched version
> of
> > > the ear plugin, it's not really a solution I favour, so I hope someone
> > can
> > > provide a better and more permanent fix.
> > >
> > > Regards,
> > > Henrik Gram
> > >
> >
>
Re: properties that are not being resolved
Posted by Henrik Østerlund Gram <he...@gmail.com>.
The one at
http://mojo.codehaus.org/buildnumber-maven-plugin/create-mojo.html ? It
states in the first couple of lines that it only works with subversion and
I'm using git.
Aside from that, I can't really see why it would make a difference; how
many ways are there to set properties? I did establish that the properties
are indeed set as I can print them via the ant-run plugin and via the a
modified ear-plugin.
On Mon, Mar 24, 2014 at 8:28 AM, Baptiste Mathus <bm...@batmat.net> wrote:
> Hi,
> Out of curiosity, why don't you use the seemingly equivalent mojo
> buildnumber maven plugin? May not be your issue, but may be the plugin
> you're using doesn't create properties in the right way (no offense, just
> trying to guess)?
> My 2 cents
> Le 23 mars 2014 22:37, "Henrik Østerlund Gram" <he...@gmail.com> a
> écrit :
>
> > I stumbled over some rather strange behaviour regarding properties. It
> > seems properties generated by one plugin are not always resolved for
> other
> > plugins and I can't figure out why.
> >
> > I use a plugin to make info about the git branch available in the
> > properties so it can be passed to other plugins. The particular plugin
> > does not seem important, but I've included it here for sake of
> > completeness:
> >
> > <plugin>
> > <groupId>com.code54.mojo</groupId>
> > <artifactId>buildversion-plugin</artifactId>
> > <version>1.0.3</version>
> > <configuration>
> > <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> > </configuration>
> > <executions>
> > <execution>
> > <goals>
> > <goal>set-properties</goal>
> > </goals>
> > </execution>
> > </executions>
> > </plugin>
> >
> > But when I referenced the properties set by the plugin in an env entry
> for
> > the maven ear plugin, the properties were not resolved at all:
> >
> > <envEntries>
> > <env-entry>
> > <description>Middleware build information</description>
> > <env-entry-name>java:app/env/sw-version</env-entry-name>
> > <env-entry-type>java.lang.String</env-entry-type>
> > <env-entry-value>${build-commit} @ ${build-tstamp} built on
> > ${maven.build.timestamp}</env-entry-value>
> > </env-entry>
> > </envEntries>
> >
> > Just to be sure, I used the latest maven and tried both version 2.9 of
> the
> > plugin and the latest from the repo with the same result.
> >
> > The only way I managed to fix this was to patch the maven-ear-plugin
> > itself, adding the following code in
> GenerateApplicationXmlMojo.execute():
> >
> > // Fix env variable substitutions
> > Properties props = project.getProperties();
> > PlexusConfiguration[] entries = envEntries.getChildren();
> > if (entries != null) {
> > for (PlexusConfiguration entry : entries) {
> > if ("env-entry".equals(entry.getName())) {
> > PlexusConfiguration[] envEntryChildren = entry.getChildren();
> > if (envEntryChildren != null) {
> > for (PlexusConfiguration envEntryChild :
> envEntryChildren)
> > {
> >
> > envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> > props));
> > }
> > }
> > }
> > }
> > }
> >
> > Then it worked just fine, but I don't understand why this is necessary.
> I
> > thought whatever called the plugin was supposed to have done the variable
> > substitution already. So clearly the properties were present at the time
> > of executing the plugin, but they werent being automaticly substituted.
> >
> > To add to the confusion, using ${project.version} in the env-entry-value
> > was resolved just fine, but just not the properties coming from another
> > plugin despite the plugins being run in the correct order.
> >
> > To further add to the confusion, I then used maven ant-run plugin,
> echoing
> > the values of properties which worked just fine (!)
> >
> > While I solved the problem for me by making a locally patched version of
> > the ear plugin, it's not really a solution I favour, so I hope someone
> can
> > provide a better and more permanent fix.
> >
> > Regards,
> > Henrik Gram
> >
>
Re: properties that are not being resolved
Posted by Baptiste Mathus <bm...@batmat.net>.
Hi,
Out of curiosity, why don't you use the seemingly equivalent mojo
buildnumber maven plugin? May not be your issue, but may be the plugin
you're using doesn't create properties in the right way (no offense, just
trying to guess)?
My 2 cents
Le 23 mars 2014 22:37, "Henrik Østerlund Gram" <he...@gmail.com> a
écrit :
> I stumbled over some rather strange behaviour regarding properties. It
> seems properties generated by one plugin are not always resolved for other
> plugins and I can't figure out why.
>
> I use a plugin to make info about the git branch available in the
> properties so it can be passed to other plugins. The particular plugin
> does not seem important, but I've included it here for sake of
> completeness:
>
> <plugin>
> <groupId>com.code54.mojo</groupId>
> <artifactId>buildversion-plugin</artifactId>
> <version>1.0.3</version>
> <configuration>
> <tstamp_format>yyyy.MM.dd HH:mm</tstamp_format>
> </configuration>
> <executions>
> <execution>
> <goals>
> <goal>set-properties</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> But when I referenced the properties set by the plugin in an env entry for
> the maven ear plugin, the properties were not resolved at all:
>
> <envEntries>
> <env-entry>
> <description>Middleware build information</description>
> <env-entry-name>java:app/env/sw-version</env-entry-name>
> <env-entry-type>java.lang.String</env-entry-type>
> <env-entry-value>${build-commit} @ ${build-tstamp} built on
> ${maven.build.timestamp}</env-entry-value>
> </env-entry>
> </envEntries>
>
> Just to be sure, I used the latest maven and tried both version 2.9 of the
> plugin and the latest from the repo with the same result.
>
> The only way I managed to fix this was to patch the maven-ear-plugin
> itself, adding the following code in GenerateApplicationXmlMojo.execute():
>
> // Fix env variable substitutions
> Properties props = project.getProperties();
> PlexusConfiguration[] entries = envEntries.getChildren();
> if (entries != null) {
> for (PlexusConfiguration entry : entries) {
> if ("env-entry".equals(entry.getName())) {
> PlexusConfiguration[] envEntryChildren = entry.getChildren();
> if (envEntryChildren != null) {
> for (PlexusConfiguration envEntryChild : envEntryChildren)
> {
>
> envEntryChild.setValue(StrSubstitutor.replace(envEntryChild.getValue(),
> props));
> }
> }
> }
> }
> }
>
> Then it worked just fine, but I don't understand why this is necessary. I
> thought whatever called the plugin was supposed to have done the variable
> substitution already. So clearly the properties were present at the time
> of executing the plugin, but they werent being automaticly substituted.
>
> To add to the confusion, using ${project.version} in the env-entry-value
> was resolved just fine, but just not the properties coming from another
> plugin despite the plugins being run in the correct order.
>
> To further add to the confusion, I then used maven ant-run plugin, echoing
> the values of properties which worked just fine (!)
>
> While I solved the problem for me by making a locally patched version of
> the ear plugin, it's not really a solution I favour, so I hope someone can
> provide a better and more permanent fix.
>
> Regards,
> Henrik Gram
>