maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henrik Østerlund Gram <henrik.g...@gmail.com>
Subject Re: properties that are not being resolved
Date Mon, 24 Mar 2014 08:04:19 GMT
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 <bmathus@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" <henrik.gram@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message