2009/1/23 Nord, James <jn...@nds.com> > > > > > > Now a second question is this.... > > > > > > if I have a pluginManagement section in the parent pom that > > specifies > > > a version of the plugin using a property *that is defined with > > > different values in both the parent and child projects*, and the > > > parent and child are not in the same reactor... what version should > > > the child project be using? > > > > > > Is it: > > > > > > A. The version defined by the property in the parent pom B. The > > > version defined by the property in the child pom. > > > > > > My feeling is that it should be A, but it's probably B! > > > > > > > OK, well help:effective-pom says that it's B. any what I > > coded works for that scenario... cool (but probably not what > > some people intend.... of course once we start ensuring that > > the deployed pom.xml has all properties resolved, it will be > > less of an issue > > Is that we "Maven" or We "your installation and plugins"? >
"We" == "Maven" in this context. AFAIK, there was/is an option/plan to have the deploy plugin deploy the resolved pom in place of the pom with property values unsubstituted. I know not the status of that... and I have no opinion as to whether it should or should not be done! -Stephen > I ask because I would not want this as a user. > > There are various plugins that all require a java version (1.4, 1.5, > 1.6) > Our site pom defines a prperty targetJDKVersion that is used to set the > jdk version to all of the plugins that require it. And so our users if > they need 1.4 or 1.6 can just set one simple property and everything > works and all the plugins are using the correct (from the project point > of view) jdk compliance. > > If you removed this feature then we would have to have all projects that > need to change the jdk to completely put back all the plugin > configurations which is error prone and then can't be as easily updated > with new config as doing it all in a single site-wide pom. > > /James > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
