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

Reply via email to