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.g...@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 <bmat...@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.g...@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 > > > > > >
