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" <[email protected]>
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 <[email protected]>
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" <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
