However, there are a few edge cases where defining a property with the same name and a different value can result in the dependency being switched... at least with M2. I have not checked M3... and it might have only been with <scope>import</scope> in which case it might actually be exactly what you want!
-Stephen On 26 October 2010 07:26, Vincent Latombe <vincent.lato...@gmail.com> wrote: > 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 <pbened...@apache.org> > >> I don't believe that's supposed to happen. >> >> On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang <farh...@gmail.com> 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 <pbened...@apache.org> >> 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 <farh...@gmail.com> >> 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 <pbened...@apache.org> >> 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 >> >>> <justinedel...@gmail.com> 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 <farh...@gmail.com> >> 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: users-unsubscr...@maven.apache.org >> >>>>> For additional commands, e-mail: users-h...@maven.apache.org >> >>>>> >> >>>>> >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> >>>> For additional commands, e-mail: users-h...@maven.apache.org >> >>>> >> >>>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> >>> For additional commands, e-mail: users-h...@maven.apache.org >> >>> >> >>> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: users-h...@maven.apache.org >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> > For additional commands, e-mail: users-h...@maven.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Vincent > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org