The ${...} string is not supposed to be replaced. It will be resolved
because the parent hierarchy is retrieved when your artifact is declared as
a dependency, so it has the whole context to resolve the property.Vincent 2010/10/26 Paul Benedict <[email protected]> > I don't believe that's supposed to happen. > > On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang <[email protected]> wrote: > >> Can you explain the "transformed pom" point? > > > > Perhaps I'm not using the correct terminology, but what I meant was > > that I looked at the pom in my local repo after I mvn install'ed it, > > and it still contains the literal ${..} string where there should have > > been the version number. > > > > Babak > > > > On Mon, Oct 25, 2010 at 6:35 PM, Paul Benedict <[email protected]> > wrote: > >> Can you explain the "transformed pom" point? I believe Justin's > >> approach and "my" approach are identical -- all you are doing is > >> delaying the version resolution until you declare the dependency. > >> Anyway, let me know how it works out. > >> > >> Paul > >> > >> On Mon, Oct 25, 2010 at 7:03 PM, Babak Farhang <[email protected]> > wrote: > >>> Paul's approach (using properties defined in the parent pom) is in > >>> fact what I've been trying. Trouble is, the transformed pom still has > >>> "${spring.version}", not the *value* it should resolve to. From a > >>> practical standpoint, this should break transitive dependencies when > >>> someone includes my project (artifact) as a dependency. > >>> > >>> Justin's approach using the <dependencyManagement> element sounds more > >>> promising. I'll report back when I've played it with it more.. > >>> > >>> Thank you all! > >>> -Babak > >>> > >>> On Mon, Oct 25, 2010 at 12:49 PM, Paul Benedict <[email protected]> > wrote: > >>>> <properties> > >>>> <spring.version>2.5.6</spring.version> > >>>> </properties> > >>>> > >>>> Then for your dependency versions, specify > <version>${spring.version}</version> > >>>> > >>>> For more information: > >>>> http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide > >>>> > >>>> Paul > >>> > >>> > >>> > >>> On Mon, Oct 25, 2010 at 12:49 PM, Justin Edelson > >>> <[email protected]> wrote: > >>>> Use a property and/or dependency management in a shared parent POM. > >>>> Spring has multiple modules, so it is frequently useful to store the > >>>> common version for all modules in a single property and then specify > >>>> each relevant module in a dependencyManagement element. > >>>> > >>>> Justin > >>> > >>> > >>> > >>> > >>>> > >>>> On Mon, Oct 25, 2010 at 1:45 PM, Babak Farhang <[email protected]> > wrote: > >>>>> Hi everyone, > >>>>> > >>>>> Say I have a number of modules that share a dependency on Spring. I'd > >>>>> like to centralize the version number of the Spring library that I'm > >>>>> using, that is, the version these modules depend on. I.e. I don't > want > >>>>> the version number of the Spring dependency to be duplicated across > >>>>> many pom files. What's the "maven way" for doing this? > >>>>> > >>>>> -Babak > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Vincent
