You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Babak Farhang <fa...@gmail.com> on 2010/10/25 20:45:27 UTC
avoiding dependency version number duplication
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: avoiding dependency version number duplication
Posted by "Yanko, Curtis" <cu...@uhc.com>.
I'd only put the version in the ParentPOM in a depMgmnt section and
then declare dependencies without versions at all.
________________________________
Curt Yanko | Continuous Integration Services | UnitedHealth Group IT
Making IT Happen, one build at a time
-----Original Message-----
From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
On Behalf Of Paul Benedict
Sent: Monday, October 25, 2010 2:49 PM
To: Maven Users List
Subject: Re: avoiding dependency version number duplication
<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 1:45 PM, Babak Farhang <fa...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Marshall Schor <ms...@schor.com>.
I may be over my head here, but I think that when you do a *release* (using the
release plugin), there is an option to have a version of the pom created for the
tag that has the properties fully resolved. See
http://maven.apache.org/plugins/maven-release-plugin/prepare-with-pom-mojo.html
Does this address your use case?
-Marshall Schor
On 10/26/2010 12:05 PM, Haszlakiewicz, Eric wrote:
>> -----Original Message-----
>> From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
> On
>> On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict <pb...@apache.org>
>> wrote:
>>> I don't believe that's supposed to happen.
>> I realized how vague my answer was. Sorry! I mean the replacement is
>> NOT supposed to happen. It's a substitution variable. You won't get
>> the real value in there because it's resolved at build time.
> Which is a problem because there's lots of other ways for that variable
> to be set that aren't going to be available after the pom is deployed.
> This has been argued about several times, and it looks like it's not
> going to get fixed because the maven people have something against
> having a build generate an appropriate pom for deployment.
>
> Babak, if you really want to make this work right, you're probably going
> to have to end up with a weird multi-stage build where first you
> generate the pom.xml file (perhaps with another pom.xml, or an ant
> build) and then build using the generated one.
>
> eric
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Babak Farhang <fa...@gmail.com>.
Thank you all for your inputs. Nice to learn that maven clients will
resolve property names by looking up their definitions in parent POMs.
This will work just fine for me.
I have another related question about properties and avoiding
duplication, which I'll start in a separate thread ;-)
Thanks again!
-Babak
On Tue, Oct 26, 2010 at 10:48 AM, Paul Benedict <pb...@apache.org> wrote:
> Well, I use properties and publish POMs with them. I don't have an
> issue with them. I am sorry the variable replacements don't meet your
> needs; I don't know what else to suggest.
>
> On Tue, Oct 26, 2010 at 11:46 AM, Haszlakiewicz, Eric
> <EH...@transunion.com> wrote:
>>>-----Original Message-----
>>>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
>> On
>>>Behalf Of Paul Benedict
>>>Sent: Tuesday, October 26, 2010 11:22 AM
>>>To: Maven Users List
>>>Subject: Re: avoiding dependency version number duplication
>>>
>>>>>Which is a problem because there's lots of other ways for that
>> variable
>>>>> to be set that aren't going to be available after the pom is
>> deployed.
>>>
>>>I wouldn't deploy a POM with variables that are not set. Won't the
>>><properties> tag be included either in the POM or the parent POM?
>>
>> Variables can be set in profiles.xml, or on the command line, or it'll
>> might be conditional based on how the build is done (e.g. "mvn -P
>> devbuild deploy" vs "mvn -P releasebuild deploy", and perhaps those
>> profile define different values).
>> Those are just the few cases that I can think of off the top of my head,
>> but I wouldn't be surprised if there are others.
>>
>> eric
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Paul Benedict <pb...@apache.org>.
Well, I use properties and publish POMs with them. I don't have an
issue with them. I am sorry the variable replacements don't meet your
needs; I don't know what else to suggest.
On Tue, Oct 26, 2010 at 11:46 AM, Haszlakiewicz, Eric
<EH...@transunion.com> wrote:
>>-----Original Message-----
>>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
> On
>>Behalf Of Paul Benedict
>>Sent: Tuesday, October 26, 2010 11:22 AM
>>To: Maven Users List
>>Subject: Re: avoiding dependency version number duplication
>>
>>>>Which is a problem because there's lots of other ways for that
> variable
>>>> to be set that aren't going to be available after the pom is
> deployed.
>>
>>I wouldn't deploy a POM with variables that are not set. Won't the
>><properties> tag be included either in the POM or the parent POM?
>
> Variables can be set in profiles.xml, or on the command line, or it'll
> might be conditional based on how the build is done (e.g. "mvn -P
> devbuild deploy" vs "mvn -P releasebuild deploy", and perhaps those
> profile define different values).
> Those are just the few cases that I can think of off the top of my head,
> but I wouldn't be surprised if there are others.
>
> eric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: avoiding dependency version number duplication
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
On
>Behalf Of Paul Benedict
>Sent: Tuesday, October 26, 2010 11:22 AM
>To: Maven Users List
>Subject: Re: avoiding dependency version number duplication
>
>>>Which is a problem because there's lots of other ways for that
variable
>>> to be set that aren't going to be available after the pom is
deployed.
>
>I wouldn't deploy a POM with variables that are not set. Won't the
><properties> tag be included either in the POM or the parent POM?
Variables can be set in profiles.xml, or on the command line, or it'll
might be conditional based on how the build is done (e.g. "mvn -P
devbuild deploy" vs "mvn -P releasebuild deploy", and perhaps those
profile define different values).
Those are just the few cases that I can think of off the top of my head,
but I wouldn't be surprised if there are others.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Paul Benedict <pb...@apache.org>.
>>Which is a problem because there's lots of other ways for that variable
>> to be set that aren't going to be available after the pom is deployed.
I wouldn't deploy a POM with variables that are not set. Won't the
<properties> tag be included either in the POM or the parent POM?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: avoiding dependency version number duplication
Posted by "Haszlakiewicz, Eric" <EH...@transunion.com>.
>-----Original Message-----
>From: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
On
>
>On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict <pb...@apache.org>
>wrote:
>> I don't believe that's supposed to happen.
>
>I realized how vague my answer was. Sorry! I mean the replacement is
>NOT supposed to happen. It's a substitution variable. You won't get
>the real value in there because it's resolved at build time.
Which is a problem because there's lots of other ways for that variable
to be set that aren't going to be available after the pom is deployed.
This has been argued about several times, and it looks like it's not
going to get fixed because the maven people have something against
having a build generate an appropriate pom for deployment.
Babak, if you really want to make this work right, you're probably going
to have to end up with a weird multi-stage build where first you
generate the pom.xml file (perhaps with another pom.xml, or an ant
build) and then build using the generated one.
eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Paul Benedict <pb...@apache.org>.
On Mon, Oct 25, 2010 at 11:09 PM, Paul Benedict <pb...@apache.org> wrote:
> I don't believe that's supposed to happen.
I realized how vague my answer was. Sorry! I mean the replacement is
NOT supposed to happen. It's a substitution variable. You won't get
the real value in there because it's resolved at build time.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Stephen Connolly <st...@gmail.com>.
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 <vi...@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 <pb...@apache.org>
>
>> I don't believe that's supposed to happen.
>>
>> On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang <fa...@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 <pb...@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 <fa...@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 <pb...@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
>> >>> <ju...@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 <fa...@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-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: users-help@maven.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: users-help@maven.apache.org
>> >>>>
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: users-help@maven.apache.org
>> >>>
>> >>>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> >> For additional commands, e-mail: users-help@maven.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> --
> Vincent
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Vincent Latombe <vi...@gmail.com>.
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 <pb...@apache.org>
> I don't believe that's supposed to happen.
>
> On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang <fa...@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 <pb...@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 <fa...@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 <pb...@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
> >>> <ju...@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 <fa...@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-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
--
Vincent
Re: avoiding dependency version number duplication
Posted by Paul Benedict <pb...@apache.org>.
I don't believe that's supposed to happen.
On Mon, Oct 25, 2010 at 7:58 PM, Babak Farhang <fa...@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 <pb...@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 <fa...@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 <pb...@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
>>> <ju...@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 <fa...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Babak Farhang <fa...@gmail.com>.
> 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 <pb...@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 <fa...@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 <pb...@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
>> <ju...@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 <fa...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Paul Benedict <pb...@apache.org>.
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 <fa...@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 <pb...@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
> <ju...@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 <fa...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Babak Farhang <fa...@gmail.com>.
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 <pb...@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
<ju...@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 <fa...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Paul Benedict <pb...@apache.org>.
<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 1:45 PM, Babak Farhang <fa...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 25/10/2010 2:45 PM, Babak Farhang 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
We made a single POM that has Spring Hibernate, MySQL and Tomcat as
dependencies with the "right" versions and gave that POM a version of
its own.
Now any project (we have 40+) that needs these libraries have a
dependency on this one POM (as "provided" since we deploy it as part of
the Tomcat lib)
This cuts the clutter by a lot and makes the project JAR much smaller.
Ron
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: avoiding dependency version number duplication
Posted by Justin Edelson <ju...@gmail.com>.
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 10/25/10 2:45 PM, Babak Farhang 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org