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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> > > 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
