no variables in /project/parent/groupId /project/parent/artifactId /project/parent/version /project/groupId /project/artifactId /project/version
is the policy you are refering to... which is to ensure that the project model can be constructed from the pom.xml that has no impact on using varibles in dependencies... in fact quite a number of maven projects use variables in dependencies to ensure that the same suite of dependencies is pulled it also has no impact on using varibles in plugins/version... again used by a number of maven projects -Stephen On 19 May 2010 20:43, Benson Margulies <[email protected]> wrote: > Doesn't the new 'no variables in versions' policy in mvn 3 make this > situation, ahem, even more difficult? Or doesn't that policy apply to > plugin > version elements in the reporting section. > > In defense of the OP: he followed a published official example that was > actively misleading. I for one think he's entitled to a small show of > temper. > > On Wed, May 19, 2010 at 2:55 PM, Wendy Smoak <[email protected]> wrote: > > > On Wed, May 19, 2010 at 1:05 PM, Tim Fulmer <[email protected]> > > wrote: > > > > > Even though the current documentation on configuring reporting shows a > > > plugin management configuration. The solution was to spam a version > > > configuration across 20 some odd POM files. I'm sure we missed a few. > > > > What docs were you looking at, so they can be improved? At least > > mention it here, but it needs to get into JIRA so it won't be > > overlooked. > > > > You might be able to set a property once and use an ${expression} for > > the version to avoid repeating it all over the place, depending on how > > your pom hierarchy is arranged. Do you have an organization level > > parent pom in place? > > > > What Maven version are you using? No idea if this is something that's > > better in Maven 3, but you might try the latest release and see if > > you're not already using it. > > > > -- > > Wendy > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
