You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Zac Thompson <za...@gmail.com> on 2010/08/24 23:54:23 UTC
how to best manage versions for a large common set of dependencies
I've racked my brain to come up with an ideal solution to this,
without success, so I'm throwing myself on the mercy of the group.
Any and all advice is greatly appreciated.
I have a project with many modules that are all released together;
let's say they're in group ca.zac.A. The parent pom (also the
aggregator) for the group defines dependencyManagement for all the
child poms so that keeping versions consistent within the group and
releasing them together is easy. So far, so good.
But other projects might depend on a subset of the group, or have
transitive dependencies on them, so I list the whole set of ca.zac.A
modules in the dependencyManagement section of each such project: I
want to be sure of keeping the versions consistent and known, and
sometimes Maven's resolution ends up choosing mixed versions. But
adding the whole set means I end up duplicating a large block of the
POM in multiple projects. And if I add a new module that might get
transitively included, then I have to update multiple places. I am
looking for a way to centralize this information.
1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
properties to affect transitive dependencies is not likely to happen
any time soon, and I wholeheartedly agree that it's a bad idea anyway.
2) The idea of inheriting from the ca.zac.A parent pom worked with
maven 2.1.0, but not well for other versions (and it smells bad
anyway).
3) I *could* list them all in dependencyManagement in my
"organizational parent" pom, with the version controlled by a single
property, but then I'd have to update it whenever a new module is
added to ca.zac.A. Having such a pom list a sizable set of my
projects is probably workable, but it feels like I'm abusing it.
4) Multiple inheritance is not supported nor desired, and I understand
that the planned "mixin" capability won't be around until post-3.0. I
could have an intermediate parent pom, with just the
dependencyManagement entries for my group, but in fact, I have more
than one such set. So I'd have to put all such groups in one pom, and
update it whenever ca.zac.A or .B or .C have a new module. This is
probably my best option, but it still feels less than ideal: I'd
rather be able to update a discrete place for each group. In
practical terms, this isn't much different than putting it in the org
parent, because I'd have to use this as the parent for most projects
anyway.
Am I stuck for now? Is there some other option I'm just not seeing?
What I find myself wishing for is something like the following, and
just have it apply to all the artifacts in the group (note that I
would only ever want to do it for a groupId that I controlled):
<dependencyManagement>
<dependencies>
<dependency>
<groupId>ca.zac.A</groupId>
<versionId>${ca.zac.A.version}</versionId>
<!-- note no artifactId is listed -->
</dependency>...
Then in the child POMs I could just specify the ca.zac.A.version
property. Is there a reason why something like this is a bad idea and
would never happen? Or should I just go ahead and submit a request
for it? It looks like there used to be a similar one at MNG-3633
(using wildcards), but that JIRA has vanished!
Should I just grin and bear it until mixins in 3.1? If so, I'll see
if there's some way I can contribute.
Zac
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how to best manage versions for a large common set of dependencies
Posted by Zac Thompson <za...@gmail.com>.
Thanks, Wayne, I'm well aware :)
I currently still have a couple of projects that use the stinky
"inheritance" solution; 2.1.0 is working for them until I have a
chance to migrate.
I'm regularly testing with 3.0 betas (#3 soon!) to make sure that I'm
ready to migrate immediately upon 3.0 release.
(To switch early I'd have to convince the development team that the
3.0 beta is "ready enough" for our production builds ... 2.2.1 is fine
until then.)
Zac
On Tue, Aug 24, 2010 at 7:52 PM, Wayne Fay <wa...@gmail.com> wrote:
>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>> maven 2.1.0, but not well for other versions (and it smells bad
>> anyway).
>
> If you're seriously using Maven 2.1.0, you need to stop ASAP. Please
> start using 2.2.1 or even the latest 3.0 beta instead.
>
> Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how to best manage versions for a large common set of dependencies
Posted by Wayne Fay <wa...@gmail.com>.
> 2) The idea of inheriting from the ca.zac.A parent pom worked with
> maven 2.1.0, but not well for other versions (and it smells bad
> anyway).
If you're seriously using Maven 2.1.0, you need to stop ASAP. Please
start using 2.2.1 or even the latest 3.0 beta instead.
Wayne
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how to best manage versions for a large common set of dependencies
Posted by Zac Thompson <za...@gmail.com>.
Thank you Stephen.
The worst part is that I remember reading about that when 2.0.9 came
out, but obviously I completely forgot about it since. I don't know
how I managed to bypass it in my searches.
Thanks again!
Zac
On Tue, Aug 24, 2010 at 3:31 PM, Stephen Connolly
<st...@gmail.com> wrote:
> I think scope>import</scope is what you are looking for, but IMHO it might
> be less than perfectly defined in the docs (last time I looked)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: how to best manage versions for a large common set of dependencies
Posted by Stephen Connolly <st...@gmail.com>.
I think scope>import</scope is what you are looking for, but IMHO it might
be less than perfectly defined in the docs (last time I looked)
On 24 August 2010 22:54, Zac Thompson <za...@gmail.com> wrote:
> I've racked my brain to come up with an ideal solution to this,
> without success, so I'm throwing myself on the mercy of the group.
> Any and all advice is greatly appreciated.
>
> I have a project with many modules that are all released together;
> let's say they're in group ca.zac.A. The parent pom (also the
> aggregator) for the group defines dependencyManagement for all the
> child poms so that keeping versions consistent within the group and
> releasing them together is easy. So far, so good.
>
> But other projects might depend on a subset of the group, or have
> transitive dependencies on them, so I list the whole set of ca.zac.A
> modules in the dependencyManagement section of each such project: I
> want to be sure of keeping the versions consistent and known, and
> sometimes Maven's resolution ends up choosing mixed versions. But
> adding the whole set means I end up duplicating a large block of the
> POM in multiple projects. And if I add a new module that might get
> transitively included, then I have to update multiple places. I am
> looking for a way to centralize this information.
>
> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
> properties to affect transitive dependencies is not likely to happen
> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>
> 2) The idea of inheriting from the ca.zac.A parent pom worked with
> maven 2.1.0, but not well for other versions (and it smells bad
> anyway).
>
> 3) I *could* list them all in dependencyManagement in my
> "organizational parent" pom, with the version controlled by a single
> property, but then I'd have to update it whenever a new module is
> added to ca.zac.A. Having such a pom list a sizable set of my
> projects is probably workable, but it feels like I'm abusing it.
>
> 4) Multiple inheritance is not supported nor desired, and I understand
> that the planned "mixin" capability won't be around until post-3.0. I
> could have an intermediate parent pom, with just the
> dependencyManagement entries for my group, but in fact, I have more
> than one such set. So I'd have to put all such groups in one pom, and
> update it whenever ca.zac.A or .B or .C have a new module. This is
> probably my best option, but it still feels less than ideal: I'd
> rather be able to update a discrete place for each group. In
> practical terms, this isn't much different than putting it in the org
> parent, because I'd have to use this as the parent for most projects
> anyway.
>
> Am I stuck for now? Is there some other option I'm just not seeing?
>
> What I find myself wishing for is something like the following, and
> just have it apply to all the artifacts in the group (note that I
> would only ever want to do it for a groupId that I controlled):
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>ca.zac.A</groupId>
> <versionId>${ca.zac.A.version}</versionId>
> <!-- note no artifactId is listed -->
> </dependency>...
>
> Then in the child POMs I could just specify the ca.zac.A.version
> property. Is there a reason why something like this is a bad idea and
> would never happen? Or should I just go ahead and submit a request
> for it? It looks like there used to be a similar one at MNG-3633
> (using wildcards), but that JIRA has vanished!
>
> Should I just grin and bear it until mixins in 3.1? If so, I'll see
> if there's some way I can contribute.
>
> Zac
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: how to best manage versions for a large common set of dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 25/08/2010 9:46 AM, Anders Hammar wrote:
> As long as you know about the drawbacks. It makes me remember all those
> trouble free days of ant..
>
> <classpath>
> <fileset dir="lib">
> <include name="**/*.jar"/>
> </fileset>
> </classpath>
>
> :-)
>
It does have a bit of that air about it from the programmers side but
1) Central control over library use does reduce the proliferation of
versions of the same package
2) Once you declare your dependence on
com.artifact_software.lms:lms-pom-spring-hibernate-mysql-tomcat:1.9.1
you don't have to guess if your module has the right core setup. Got
tired of finding spring 2.0.5 jars in webapps that were part of an
application that was supposed to be running 2.5.6
3) Pom files are much simpler to standardize.
4) Much easier to on-board a new person. If you want to know what Apache
packages are in use and can be used without raising a team discussion,
just look at the lms-pom-shared.
5) When we went from Tomcat 5 to 6, I did not have to look through 40
webapps to be sure that no one had a Tomcat 5 jar stuck somewhere.
On the downside it does make "where used" a bit tougher for the less
ubiquitous libraries like Apache POI which is only used in 3 or 4
webapps. it is in "shared" so all projects "might" be using it as far as
Maven is concerned.
Ron
> /Anders
>
> On Wed, Aug 25, 2010 at 15:30, Ron Wheeler
> <rw...@artifact-software.com>wrote:
>
>> On 25/08/2010 9:07 AM, Anders Hammar wrote:
>>
>>> What I was thinking of was that you could get transitive dependencies
>>> included which are actually also included in your "super-jar". As the
>>> super-jar is of a different GA than the original/correct artifact, Maven
>>> will have no chance to handle that but you need to exclude that manually.
>>> In
>>> my experience, no normal Java developer will have a clue about this.
>>>
>> The developers generally do not have to add any dependencies to their poms
>> other than the libraries that we have agreed on.
>> This simplifies their lives since they do not have to worry about third
>> party jars.
>> If there is a new library added to an individual module, the maven
>> dependency hierarchy window identifies conflicts which can then be raised
>> with the team to see how it should be resolved.
>>
>> Ron
>>
>> As the dependency grouping pom solves this issue I see it as a better
>>> Maven
>>> solution. However, it will make your deployment to the server involve a
>>> little bit more work as you need to copy more than one jar. But I assume
>>> you
>>> have tools to do this so it shouldn't be an issue, right?
>>>
>>> /Anders
>>>
>>> On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
>>> <rw...@artifact-software.com>wrote:
>>>
>>> On 25/08/2010 2:45 AM, Anders Hammar wrote:
>>>> I don't think that I would call Ron's solution a best-practice (I see
>>>>> issues
>>>>> with transitive dependencies).
>>>>>
>>>>> Can you elaborate? We have not found any problems yet but perhaps we
>>>> have
>>>> been lucky.
>>>> We do pay attention to version conflicts while building the aggregate
>>>> jars.
>>>> Are we missing something?
>>>>
>>>>
>>>> If you want something as simple as just
>>>>
>>>>> adding one dependency, you should create a pom project that groups these
>>>>> dependencies. Tim explains this in this blog post:
>>>>>
>>>>>
>>>>> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>>>>>
>>>>> However, be aware that there are drawbacks with this solution. For one,
>>>>> the
>>>>> "mvn dependency:analyze" won't work as the dependencies go one the wrong
>>>>> level. The import pom solution that Stephen suggests does not have this
>>>>> limitation, which is very nice.
>>>>>
>>>>> /Anders
>>>>>
>>>>> On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
>>>>> <rw...@artifact-software.com>wrote:
>>>>>
>>>>> This is a common problem in a portal environment or SOA architecture
>>>>>
>>>>>> where
>>>>>> many webapps are generated.
>>>>>> We solved this by creating a set of projects that create sets of jars
>>>>>> that
>>>>>> group together a bunch of jars into one massive jar.
>>>>>>
>>>>>> For example, we have a spring-mysql-hibernate-tomcat project that
>>>>>> creates
>>>>>> an aggregated jar with all of the libraries included in this set of
>>>>>> projects.
>>>>>> The POM that manages this project has all the version numbers so the
>>>>>> parent
>>>>>> pom of all of the modules only specifies the application version and
>>>>>> the
>>>>>> module only depends on our set of aggregated POMs.
>>>>>>
>>>>>> If you want to change the version of a Hibernate library you only have
>>>>>> to
>>>>>> change it in one place.
>>>>>> The POMs that create individual application artifacts do not know
>>>>>> anything
>>>>>> about the version of Hibernate, they only depend on the current
>>>>>> ($project.version) version of the application to get all the right bits
>>>>>> and
>>>>>> pieces of spring, mysql, hibernate and tomcat.
>>>>>>
>>>>>> This really simplifies the management of individual portlets or web
>>>>>> services.
>>>>>> They call on one parent POM that specifies the {$project.version} and
>>>>>> use
>>>>>> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
>>>>>> CXF,
>>>>>> etc.
>>>>>> This means that a module's POM is very stable and only has 4 or 5
>>>>>> dependencies.
>>>>>> We also deploy the aggregated jars into the Tomcat shared library.
>>>>>>
>>>>>> This makes the webapps very small and reduces the number of choices
>>>>>> that
>>>>>> a
>>>>>> developer has to make about third party jars.
>>>>>>
>>>>>> Ron
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>>>>>>
>>>>>> I've racked my brain to come up with an ideal solution to this,
>>>>>>
>>>>>>> without success, so I'm throwing myself on the mercy of the group.
>>>>>>> Any and all advice is greatly appreciated.
>>>>>>>
>>>>>>> I have a project with many modules that are all released together;
>>>>>>> let's say they're in group ca.zac.A. The parent pom (also the
>>>>>>> aggregator) for the group defines dependencyManagement for all the
>>>>>>> child poms so that keeping versions consistent within the group and
>>>>>>> releasing them together is easy. So far, so good.
>>>>>>>
>>>>>>> But other projects might depend on a subset of the group, or have
>>>>>>> transitive dependencies on them, so I list the whole set of ca.zac.A
>>>>>>> modules in the dependencyManagement section of each such project: I
>>>>>>> want to be sure of keeping the versions consistent and known, and
>>>>>>> sometimes Maven's resolution ends up choosing mixed versions. But
>>>>>>> adding the whole set means I end up duplicating a large block of the
>>>>>>> POM in multiple projects. And if I add a new module that might get
>>>>>>> transitively included, then I have to update multiple places. I am
>>>>>>> looking for a way to centralize this information.
>>>>>>>
>>>>>>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>>>>>>> properties to affect transitive dependencies is not likely to happen
>>>>>>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>>>>>>
>>>>>>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>>>>>>> maven 2.1.0, but not well for other versions (and it smells bad
>>>>>>> anyway).
>>>>>>>
>>>>>>> 3) I *could* list them all in dependencyManagement in my
>>>>>>> "organizational parent" pom, with the version controlled by a single
>>>>>>> property, but then I'd have to update it whenever a new module is
>>>>>>> added to ca.zac.A. Having such a pom list a sizable set of my
>>>>>>> projects is probably workable, but it feels like I'm abusing it.
>>>>>>>
>>>>>>> 4) Multiple inheritance is not supported nor desired, and I understand
>>>>>>> that the planned "mixin" capability won't be around until post-3.0. I
>>>>>>> could have an intermediate parent pom, with just the
>>>>>>> dependencyManagement entries for my group, but in fact, I have more
>>>>>>> than one such set. So I'd have to put all such groups in one pom, and
>>>>>>> update it whenever ca.zac.A or .B or .C have a new module. This is
>>>>>>> probably my best option, but it still feels less than ideal: I'd
>>>>>>> rather be able to update a discrete place for each group. In
>>>>>>> practical terms, this isn't much different than putting it in the org
>>>>>>> parent, because I'd have to use this as the parent for most projects
>>>>>>> anyway.
>>>>>>>
>>>>>>> Am I stuck for now? Is there some other option I'm just not seeing?
>>>>>>>
>>>>>>> What I find myself wishing for is something like the following, and
>>>>>>> just have it apply to all the artifacts in the group (note that I
>>>>>>> would only ever want to do it for a groupId that I controlled):
>>>>>>>
>>>>>>> <dependencyManagement>
>>>>>>> <dependencies>
>>>>>>> <dependency>
>>>>>>> <groupId>ca.zac.A</groupId>
>>>>>>> <versionId>${ca.zac.A.version}</versionId>
>>>>>>> <!-- note no artifactId is listed -->
>>>>>>> </dependency>...
>>>>>>>
>>>>>>> Then in the child POMs I could just specify the ca.zac.A.version
>>>>>>> property. Is there a reason why something like this is a bad idea and
>>>>>>> would never happen? Or should I just go ahead and submit a request
>>>>>>> for it? It looks like there used to be a similar one at MNG-3633
>>>>>>> (using wildcards), but that JIRA has vanished!
>>>>>>>
>>>>>>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>>>>>>> if there's some way I can contribute.
>>>>>>>
>>>>>>> Zac
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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: how to best manage versions for a large common set of dependencies
Posted by Anders Hammar <an...@hammar.net>.
As long as you know about the drawbacks. It makes me remember all those
trouble free days of ant..
<classpath>
<fileset dir="lib">
<include name="**/*.jar"/>
</fileset>
</classpath>
:-)
/Anders
On Wed, Aug 25, 2010 at 15:30, Ron Wheeler
<rw...@artifact-software.com>wrote:
> On 25/08/2010 9:07 AM, Anders Hammar wrote:
>
>> What I was thinking of was that you could get transitive dependencies
>> included which are actually also included in your "super-jar". As the
>> super-jar is of a different GA than the original/correct artifact, Maven
>> will have no chance to handle that but you need to exclude that manually.
>> In
>> my experience, no normal Java developer will have a clue about this.
>>
> The developers generally do not have to add any dependencies to their poms
> other than the libraries that we have agreed on.
> This simplifies their lives since they do not have to worry about third
> party jars.
> If there is a new library added to an individual module, the maven
> dependency hierarchy window identifies conflicts which can then be raised
> with the team to see how it should be resolved.
>
> Ron
>
> As the dependency grouping pom solves this issue I see it as a better
>> Maven
>> solution. However, it will make your deployment to the server involve a
>> little bit more work as you need to copy more than one jar. But I assume
>> you
>> have tools to do this so it shouldn't be an issue, right?
>>
>> /Anders
>>
>> On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
>> <rw...@artifact-software.com>wrote:
>>
>> On 25/08/2010 2:45 AM, Anders Hammar wrote:
>>>
>>> I don't think that I would call Ron's solution a best-practice (I see
>>>> issues
>>>> with transitive dependencies).
>>>>
>>>> Can you elaborate? We have not found any problems yet but perhaps we
>>> have
>>> been lucky.
>>> We do pay attention to version conflicts while building the aggregate
>>> jars.
>>> Are we missing something?
>>>
>>>
>>> If you want something as simple as just
>>>
>>>> adding one dependency, you should create a pom project that groups these
>>>> dependencies. Tim explains this in this blog post:
>>>>
>>>>
>>>> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>>>>
>>>> However, be aware that there are drawbacks with this solution. For one,
>>>> the
>>>> "mvn dependency:analyze" won't work as the dependencies go one the wrong
>>>> level. The import pom solution that Stephen suggests does not have this
>>>> limitation, which is very nice.
>>>>
>>>> /Anders
>>>>
>>>> On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
>>>> <rw...@artifact-software.com>wrote:
>>>>
>>>> This is a common problem in a portal environment or SOA architecture
>>>>
>>>>> where
>>>>> many webapps are generated.
>>>>> We solved this by creating a set of projects that create sets of jars
>>>>> that
>>>>> group together a bunch of jars into one massive jar.
>>>>>
>>>>> For example, we have a spring-mysql-hibernate-tomcat project that
>>>>> creates
>>>>> an aggregated jar with all of the libraries included in this set of
>>>>> projects.
>>>>> The POM that manages this project has all the version numbers so the
>>>>> parent
>>>>> pom of all of the modules only specifies the application version and
>>>>> the
>>>>> module only depends on our set of aggregated POMs.
>>>>>
>>>>> If you want to change the version of a Hibernate library you only have
>>>>> to
>>>>> change it in one place.
>>>>> The POMs that create individual application artifacts do not know
>>>>> anything
>>>>> about the version of Hibernate, they only depend on the current
>>>>> ($project.version) version of the application to get all the right bits
>>>>> and
>>>>> pieces of spring, mysql, hibernate and tomcat.
>>>>>
>>>>> This really simplifies the management of individual portlets or web
>>>>> services.
>>>>> They call on one parent POM that specifies the {$project.version} and
>>>>> use
>>>>> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
>>>>> CXF,
>>>>> etc.
>>>>> This means that a module's POM is very stable and only has 4 or 5
>>>>> dependencies.
>>>>> We also deploy the aggregated jars into the Tomcat shared library.
>>>>>
>>>>> This makes the webapps very small and reduces the number of choices
>>>>> that
>>>>> a
>>>>> developer has to make about third party jars.
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>>>>>
>>>>> I've racked my brain to come up with an ideal solution to this,
>>>>>
>>>>>> without success, so I'm throwing myself on the mercy of the group.
>>>>>> Any and all advice is greatly appreciated.
>>>>>>
>>>>>> I have a project with many modules that are all released together;
>>>>>> let's say they're in group ca.zac.A. The parent pom (also the
>>>>>> aggregator) for the group defines dependencyManagement for all the
>>>>>> child poms so that keeping versions consistent within the group and
>>>>>> releasing them together is easy. So far, so good.
>>>>>>
>>>>>> But other projects might depend on a subset of the group, or have
>>>>>> transitive dependencies on them, so I list the whole set of ca.zac.A
>>>>>> modules in the dependencyManagement section of each such project: I
>>>>>> want to be sure of keeping the versions consistent and known, and
>>>>>> sometimes Maven's resolution ends up choosing mixed versions. But
>>>>>> adding the whole set means I end up duplicating a large block of the
>>>>>> POM in multiple projects. And if I add a new module that might get
>>>>>> transitively included, then I have to update multiple places. I am
>>>>>> looking for a way to centralize this information.
>>>>>>
>>>>>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>>>>>> properties to affect transitive dependencies is not likely to happen
>>>>>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>>>>>
>>>>>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>>>>>> maven 2.1.0, but not well for other versions (and it smells bad
>>>>>> anyway).
>>>>>>
>>>>>> 3) I *could* list them all in dependencyManagement in my
>>>>>> "organizational parent" pom, with the version controlled by a single
>>>>>> property, but then I'd have to update it whenever a new module is
>>>>>> added to ca.zac.A. Having such a pom list a sizable set of my
>>>>>> projects is probably workable, but it feels like I'm abusing it.
>>>>>>
>>>>>> 4) Multiple inheritance is not supported nor desired, and I understand
>>>>>> that the planned "mixin" capability won't be around until post-3.0. I
>>>>>> could have an intermediate parent pom, with just the
>>>>>> dependencyManagement entries for my group, but in fact, I have more
>>>>>> than one such set. So I'd have to put all such groups in one pom, and
>>>>>> update it whenever ca.zac.A or .B or .C have a new module. This is
>>>>>> probably my best option, but it still feels less than ideal: I'd
>>>>>> rather be able to update a discrete place for each group. In
>>>>>> practical terms, this isn't much different than putting it in the org
>>>>>> parent, because I'd have to use this as the parent for most projects
>>>>>> anyway.
>>>>>>
>>>>>> Am I stuck for now? Is there some other option I'm just not seeing?
>>>>>>
>>>>>> What I find myself wishing for is something like the following, and
>>>>>> just have it apply to all the artifacts in the group (note that I
>>>>>> would only ever want to do it for a groupId that I controlled):
>>>>>>
>>>>>> <dependencyManagement>
>>>>>> <dependencies>
>>>>>> <dependency>
>>>>>> <groupId>ca.zac.A</groupId>
>>>>>> <versionId>${ca.zac.A.version}</versionId>
>>>>>> <!-- note no artifactId is listed -->
>>>>>> </dependency>...
>>>>>>
>>>>>> Then in the child POMs I could just specify the ca.zac.A.version
>>>>>> property. Is there a reason why something like this is a bad idea and
>>>>>> would never happen? Or should I just go ahead and submit a request
>>>>>> for it? It looks like there used to be a similar one at MNG-3633
>>>>>> (using wildcards), but that JIRA has vanished!
>>>>>>
>>>>>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>>>>>> if there's some way I can contribute.
>>>>>>
>>>>>> Zac
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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: how to best manage versions for a large common set of dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 25/08/2010 9:07 AM, Anders Hammar wrote:
> What I was thinking of was that you could get transitive dependencies
> included which are actually also included in your "super-jar". As the
> super-jar is of a different GA than the original/correct artifact, Maven
> will have no chance to handle that but you need to exclude that manually. In
> my experience, no normal Java developer will have a clue about this.
The developers generally do not have to add any dependencies to their
poms other than the libraries that we have agreed on.
This simplifies their lives since they do not have to worry about third
party jars.
If there is a new library added to an individual module, the maven
dependency hierarchy window identifies conflicts which can then be
raised with the team to see how it should be resolved.
Ron
> As the dependency grouping pom solves this issue I see it as a better Maven
> solution. However, it will make your deployment to the server involve a
> little bit more work as you need to copy more than one jar. But I assume you
> have tools to do this so it shouldn't be an issue, right?
>
> /Anders
>
> On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
> <rw...@artifact-software.com>wrote:
>
>> On 25/08/2010 2:45 AM, Anders Hammar wrote:
>>
>>> I don't think that I would call Ron's solution a best-practice (I see
>>> issues
>>> with transitive dependencies).
>>>
>> Can you elaborate? We have not found any problems yet but perhaps we have
>> been lucky.
>> We do pay attention to version conflicts while building the aggregate jars.
>> Are we missing something?
>>
>>
>> If you want something as simple as just
>>> adding one dependency, you should create a pom project that groups these
>>> dependencies. Tim explains this in this blog post:
>>>
>>> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>>>
>>> However, be aware that there are drawbacks with this solution. For one,
>>> the
>>> "mvn dependency:analyze" won't work as the dependencies go one the wrong
>>> level. The import pom solution that Stephen suggests does not have this
>>> limitation, which is very nice.
>>>
>>> /Anders
>>>
>>> On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
>>> <rw...@artifact-software.com>wrote:
>>>
>>> This is a common problem in a portal environment or SOA architecture
>>>> where
>>>> many webapps are generated.
>>>> We solved this by creating a set of projects that create sets of jars
>>>> that
>>>> group together a bunch of jars into one massive jar.
>>>>
>>>> For example, we have a spring-mysql-hibernate-tomcat project that creates
>>>> an aggregated jar with all of the libraries included in this set of
>>>> projects.
>>>> The POM that manages this project has all the version numbers so the
>>>> parent
>>>> pom of all of the modules only specifies the application version and the
>>>> module only depends on our set of aggregated POMs.
>>>>
>>>> If you want to change the version of a Hibernate library you only have to
>>>> change it in one place.
>>>> The POMs that create individual application artifacts do not know
>>>> anything
>>>> about the version of Hibernate, they only depend on the current
>>>> ($project.version) version of the application to get all the right bits
>>>> and
>>>> pieces of spring, mysql, hibernate and tomcat.
>>>>
>>>> This really simplifies the management of individual portlets or web
>>>> services.
>>>> They call on one parent POM that specifies the {$project.version} and use
>>>> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
>>>> CXF,
>>>> etc.
>>>> This means that a module's POM is very stable and only has 4 or 5
>>>> dependencies.
>>>> We also deploy the aggregated jars into the Tomcat shared library.
>>>>
>>>> This makes the webapps very small and reduces the number of choices that
>>>> a
>>>> developer has to make about third party jars.
>>>>
>>>> Ron
>>>>
>>>>
>>>>
>>>>
>>>> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>>>>
>>>> I've racked my brain to come up with an ideal solution to this,
>>>>> without success, so I'm throwing myself on the mercy of the group.
>>>>> Any and all advice is greatly appreciated.
>>>>>
>>>>> I have a project with many modules that are all released together;
>>>>> let's say they're in group ca.zac.A. The parent pom (also the
>>>>> aggregator) for the group defines dependencyManagement for all the
>>>>> child poms so that keeping versions consistent within the group and
>>>>> releasing them together is easy. So far, so good.
>>>>>
>>>>> But other projects might depend on a subset of the group, or have
>>>>> transitive dependencies on them, so I list the whole set of ca.zac.A
>>>>> modules in the dependencyManagement section of each such project: I
>>>>> want to be sure of keeping the versions consistent and known, and
>>>>> sometimes Maven's resolution ends up choosing mixed versions. But
>>>>> adding the whole set means I end up duplicating a large block of the
>>>>> POM in multiple projects. And if I add a new module that might get
>>>>> transitively included, then I have to update multiple places. I am
>>>>> looking for a way to centralize this information.
>>>>>
>>>>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>>>>> properties to affect transitive dependencies is not likely to happen
>>>>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>>>>
>>>>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>>>>> maven 2.1.0, but not well for other versions (and it smells bad
>>>>> anyway).
>>>>>
>>>>> 3) I *could* list them all in dependencyManagement in my
>>>>> "organizational parent" pom, with the version controlled by a single
>>>>> property, but then I'd have to update it whenever a new module is
>>>>> added to ca.zac.A. Having such a pom list a sizable set of my
>>>>> projects is probably workable, but it feels like I'm abusing it.
>>>>>
>>>>> 4) Multiple inheritance is not supported nor desired, and I understand
>>>>> that the planned "mixin" capability won't be around until post-3.0. I
>>>>> could have an intermediate parent pom, with just the
>>>>> dependencyManagement entries for my group, but in fact, I have more
>>>>> than one such set. So I'd have to put all such groups in one pom, and
>>>>> update it whenever ca.zac.A or .B or .C have a new module. This is
>>>>> probably my best option, but it still feels less than ideal: I'd
>>>>> rather be able to update a discrete place for each group. In
>>>>> practical terms, this isn't much different than putting it in the org
>>>>> parent, because I'd have to use this as the parent for most projects
>>>>> anyway.
>>>>>
>>>>> Am I stuck for now? Is there some other option I'm just not seeing?
>>>>>
>>>>> What I find myself wishing for is something like the following, and
>>>>> just have it apply to all the artifacts in the group (note that I
>>>>> would only ever want to do it for a groupId that I controlled):
>>>>>
>>>>> <dependencyManagement>
>>>>> <dependencies>
>>>>> <dependency>
>>>>> <groupId>ca.zac.A</groupId>
>>>>> <versionId>${ca.zac.A.version}</versionId>
>>>>> <!-- note no artifactId is listed -->
>>>>> </dependency>...
>>>>>
>>>>> Then in the child POMs I could just specify the ca.zac.A.version
>>>>> property. Is there a reason why something like this is a bad idea and
>>>>> would never happen? Or should I just go ahead and submit a request
>>>>> for it? It looks like there used to be a similar one at MNG-3633
>>>>> (using wildcards), but that JIRA has vanished!
>>>>>
>>>>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>>>>> if there's some way I can contribute.
>>>>>
>>>>> Zac
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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: how to best manage versions for a large common set of dependencies
Posted by Anders Hammar <an...@hammar.net>.
What I was thinking of was that you could get transitive dependencies
included which are actually also included in your "super-jar". As the
super-jar is of a different GA than the original/correct artifact, Maven
will have no chance to handle that but you need to exclude that manually. In
my experience, no normal Java developer will have a clue about this.
As the dependency grouping pom solves this issue I see it as a better Maven
solution. However, it will make your deployment to the server involve a
little bit more work as you need to copy more than one jar. But I assume you
have tools to do this so it shouldn't be an issue, right?
/Anders
On Wed, Aug 25, 2010 at 13:59, Ron Wheeler
<rw...@artifact-software.com>wrote:
> On 25/08/2010 2:45 AM, Anders Hammar wrote:
>
>> I don't think that I would call Ron's solution a best-practice (I see
>> issues
>> with transitive dependencies).
>>
> Can you elaborate? We have not found any problems yet but perhaps we have
> been lucky.
> We do pay attention to version conflicts while building the aggregate jars.
> Are we missing something?
>
>
> If you want something as simple as just
>> adding one dependency, you should create a pom project that groups these
>> dependencies. Tim explains this in this blog post:
>>
>> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>>
>> However, be aware that there are drawbacks with this solution. For one,
>> the
>> "mvn dependency:analyze" won't work as the dependencies go one the wrong
>> level. The import pom solution that Stephen suggests does not have this
>> limitation, which is very nice.
>>
>> /Anders
>>
>> On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
>> <rw...@artifact-software.com>wrote:
>>
>> This is a common problem in a portal environment or SOA architecture
>>> where
>>> many webapps are generated.
>>> We solved this by creating a set of projects that create sets of jars
>>> that
>>> group together a bunch of jars into one massive jar.
>>>
>>> For example, we have a spring-mysql-hibernate-tomcat project that creates
>>> an aggregated jar with all of the libraries included in this set of
>>> projects.
>>> The POM that manages this project has all the version numbers so the
>>> parent
>>> pom of all of the modules only specifies the application version and the
>>> module only depends on our set of aggregated POMs.
>>>
>>> If you want to change the version of a Hibernate library you only have to
>>> change it in one place.
>>> The POMs that create individual application artifacts do not know
>>> anything
>>> about the version of Hibernate, they only depend on the current
>>> ($project.version) version of the application to get all the right bits
>>> and
>>> pieces of spring, mysql, hibernate and tomcat.
>>>
>>> This really simplifies the management of individual portlets or web
>>> services.
>>> They call on one parent POM that specifies the {$project.version} and use
>>> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf,
>>> CXF,
>>> etc.
>>> This means that a module's POM is very stable and only has 4 or 5
>>> dependencies.
>>> We also deploy the aggregated jars into the Tomcat shared library.
>>>
>>> This makes the webapps very small and reduces the number of choices that
>>> a
>>> developer has to make about third party jars.
>>>
>>> Ron
>>>
>>>
>>>
>>>
>>> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>>>
>>> I've racked my brain to come up with an ideal solution to this,
>>>> without success, so I'm throwing myself on the mercy of the group.
>>>> Any and all advice is greatly appreciated.
>>>>
>>>> I have a project with many modules that are all released together;
>>>> let's say they're in group ca.zac.A. The parent pom (also the
>>>> aggregator) for the group defines dependencyManagement for all the
>>>> child poms so that keeping versions consistent within the group and
>>>> releasing them together is easy. So far, so good.
>>>>
>>>> But other projects might depend on a subset of the group, or have
>>>> transitive dependencies on them, so I list the whole set of ca.zac.A
>>>> modules in the dependencyManagement section of each such project: I
>>>> want to be sure of keeping the versions consistent and known, and
>>>> sometimes Maven's resolution ends up choosing mixed versions. But
>>>> adding the whole set means I end up duplicating a large block of the
>>>> POM in multiple projects. And if I add a new module that might get
>>>> transitively included, then I have to update multiple places. I am
>>>> looking for a way to centralize this information.
>>>>
>>>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>>>> properties to affect transitive dependencies is not likely to happen
>>>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>>>
>>>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>>>> maven 2.1.0, but not well for other versions (and it smells bad
>>>> anyway).
>>>>
>>>> 3) I *could* list them all in dependencyManagement in my
>>>> "organizational parent" pom, with the version controlled by a single
>>>> property, but then I'd have to update it whenever a new module is
>>>> added to ca.zac.A. Having such a pom list a sizable set of my
>>>> projects is probably workable, but it feels like I'm abusing it.
>>>>
>>>> 4) Multiple inheritance is not supported nor desired, and I understand
>>>> that the planned "mixin" capability won't be around until post-3.0. I
>>>> could have an intermediate parent pom, with just the
>>>> dependencyManagement entries for my group, but in fact, I have more
>>>> than one such set. So I'd have to put all such groups in one pom, and
>>>> update it whenever ca.zac.A or .B or .C have a new module. This is
>>>> probably my best option, but it still feels less than ideal: I'd
>>>> rather be able to update a discrete place for each group. In
>>>> practical terms, this isn't much different than putting it in the org
>>>> parent, because I'd have to use this as the parent for most projects
>>>> anyway.
>>>>
>>>> Am I stuck for now? Is there some other option I'm just not seeing?
>>>>
>>>> What I find myself wishing for is something like the following, and
>>>> just have it apply to all the artifacts in the group (note that I
>>>> would only ever want to do it for a groupId that I controlled):
>>>>
>>>> <dependencyManagement>
>>>> <dependencies>
>>>> <dependency>
>>>> <groupId>ca.zac.A</groupId>
>>>> <versionId>${ca.zac.A.version}</versionId>
>>>> <!-- note no artifactId is listed -->
>>>> </dependency>...
>>>>
>>>> Then in the child POMs I could just specify the ca.zac.A.version
>>>> property. Is there a reason why something like this is a bad idea and
>>>> would never happen? Or should I just go ahead and submit a request
>>>> for it? It looks like there used to be a similar one at MNG-3633
>>>> (using wildcards), but that JIRA has vanished!
>>>>
>>>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>>>> if there's some way I can contribute.
>>>>
>>>> Zac
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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: how to best manage versions for a large common set of dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
On 25/08/2010 2:45 AM, Anders Hammar wrote:
> I don't think that I would call Ron's solution a best-practice (I see issues
> with transitive dependencies).
Can you elaborate? We have not found any problems yet but perhaps we
have been lucky.
We do pay attention to version conflicts while building the aggregate jars.
Are we missing something?
> If you want something as simple as just
> adding one dependency, you should create a pom project that groups these
> dependencies. Tim explains this in this blog post:
> http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
>
> However, be aware that there are drawbacks with this solution. For one, the
> "mvn dependency:analyze" won't work as the dependencies go one the wrong
> level. The import pom solution that Stephen suggests does not have this
> limitation, which is very nice.
>
> /Anders
>
> On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
> <rw...@artifact-software.com>wrote:
>
>> This is a common problem in a portal environment or SOA architecture where
>> many webapps are generated.
>> We solved this by creating a set of projects that create sets of jars that
>> group together a bunch of jars into one massive jar.
>>
>> For example, we have a spring-mysql-hibernate-tomcat project that creates
>> an aggregated jar with all of the libraries included in this set of
>> projects.
>> The POM that manages this project has all the version numbers so the parent
>> pom of all of the modules only specifies the application version and the
>> module only depends on our set of aggregated POMs.
>>
>> If you want to change the version of a Hibernate library you only have to
>> change it in one place.
>> The POMs that create individual application artifacts do not know anything
>> about the version of Hibernate, they only depend on the current
>> ($project.version) version of the application to get all the right bits and
>> pieces of spring, mysql, hibernate and tomcat.
>>
>> This really simplifies the management of individual portlets or web
>> services.
>> They call on one parent POM that specifies the {$project.version} and use
>> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf, CXF,
>> etc.
>> This means that a module's POM is very stable and only has 4 or 5
>> dependencies.
>> We also deploy the aggregated jars into the Tomcat shared library.
>>
>> This makes the webapps very small and reduces the number of choices that a
>> developer has to make about third party jars.
>>
>> Ron
>>
>>
>>
>>
>> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>>
>>> I've racked my brain to come up with an ideal solution to this,
>>> without success, so I'm throwing myself on the mercy of the group.
>>> Any and all advice is greatly appreciated.
>>>
>>> I have a project with many modules that are all released together;
>>> let's say they're in group ca.zac.A. The parent pom (also the
>>> aggregator) for the group defines dependencyManagement for all the
>>> child poms so that keeping versions consistent within the group and
>>> releasing them together is easy. So far, so good.
>>>
>>> But other projects might depend on a subset of the group, or have
>>> transitive dependencies on them, so I list the whole set of ca.zac.A
>>> modules in the dependencyManagement section of each such project: I
>>> want to be sure of keeping the versions consistent and known, and
>>> sometimes Maven's resolution ends up choosing mixed versions. But
>>> adding the whole set means I end up duplicating a large block of the
>>> POM in multiple projects. And if I add a new module that might get
>>> transitively included, then I have to update multiple places. I am
>>> looking for a way to centralize this information.
>>>
>>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>>> properties to affect transitive dependencies is not likely to happen
>>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>>
>>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>>> maven 2.1.0, but not well for other versions (and it smells bad
>>> anyway).
>>>
>>> 3) I *could* list them all in dependencyManagement in my
>>> "organizational parent" pom, with the version controlled by a single
>>> property, but then I'd have to update it whenever a new module is
>>> added to ca.zac.A. Having such a pom list a sizable set of my
>>> projects is probably workable, but it feels like I'm abusing it.
>>>
>>> 4) Multiple inheritance is not supported nor desired, and I understand
>>> that the planned "mixin" capability won't be around until post-3.0. I
>>> could have an intermediate parent pom, with just the
>>> dependencyManagement entries for my group, but in fact, I have more
>>> than one such set. So I'd have to put all such groups in one pom, and
>>> update it whenever ca.zac.A or .B or .C have a new module. This is
>>> probably my best option, but it still feels less than ideal: I'd
>>> rather be able to update a discrete place for each group. In
>>> practical terms, this isn't much different than putting it in the org
>>> parent, because I'd have to use this as the parent for most projects
>>> anyway.
>>>
>>> Am I stuck for now? Is there some other option I'm just not seeing?
>>>
>>> What I find myself wishing for is something like the following, and
>>> just have it apply to all the artifacts in the group (note that I
>>> would only ever want to do it for a groupId that I controlled):
>>>
>>> <dependencyManagement>
>>> <dependencies>
>>> <dependency>
>>> <groupId>ca.zac.A</groupId>
>>> <versionId>${ca.zac.A.version}</versionId>
>>> <!-- note no artifactId is listed -->
>>> </dependency>...
>>>
>>> Then in the child POMs I could just specify the ca.zac.A.version
>>> property. Is there a reason why something like this is a bad idea and
>>> would never happen? Or should I just go ahead and submit a request
>>> for it? It looks like there used to be a similar one at MNG-3633
>>> (using wildcards), but that JIRA has vanished!
>>>
>>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>>> if there's some way I can contribute.
>>>
>>> Zac
>>>
>>> ---------------------------------------------------------------------
>>> 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: how to best manage versions for a large common set of dependencies
Posted by Anders Hammar <an...@hammar.net>.
I don't think that I would call Ron's solution a best-practice (I see issues
with transitive dependencies). If you want something as simple as just
adding one dependency, you should create a pom project that groups these
dependencies. Tim explains this in this blog post:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-grouping-dependencies/
However, be aware that there are drawbacks with this solution. For one, the
"mvn dependency:analyze" won't work as the dependencies go one the wrong
level. The import pom solution that Stephen suggests does not have this
limitation, which is very nice.
/Anders
On Wed, Aug 25, 2010 at 06:26, Ron Wheeler
<rw...@artifact-software.com>wrote:
> This is a common problem in a portal environment or SOA architecture where
> many webapps are generated.
> We solved this by creating a set of projects that create sets of jars that
> group together a bunch of jars into one massive jar.
>
> For example, we have a spring-mysql-hibernate-tomcat project that creates
> an aggregated jar with all of the libraries included in this set of
> projects.
> The POM that manages this project has all the version numbers so the parent
> pom of all of the modules only specifies the application version and the
> module only depends on our set of aggregated POMs.
>
> If you want to change the version of a Hibernate library you only have to
> change it in one place.
> The POMs that create individual application artifacts do not know anything
> about the version of Hibernate, they only depend on the current
> ($project.version) version of the application to get all the right bits and
> pieces of spring, mysql, hibernate and tomcat.
>
> This really simplifies the management of individual portlets or web
> services.
> They call on one parent POM that specifies the {$project.version} and use
> this variable in the dependency for spring-mysql-hibernate-tomcat, jsf, CXF,
> etc.
> This means that a module's POM is very stable and only has 4 or 5
> dependencies.
> We also deploy the aggregated jars into the Tomcat shared library.
>
> This makes the webapps very small and reduces the number of choices that a
> developer has to make about third party jars.
>
> Ron
>
>
>
>
> On 24/08/2010 5:54 PM, Zac Thompson wrote:
>
>> I've racked my brain to come up with an ideal solution to this,
>> without success, so I'm throwing myself on the mercy of the group.
>> Any and all advice is greatly appreciated.
>>
>> I have a project with many modules that are all released together;
>> let's say they're in group ca.zac.A. The parent pom (also the
>> aggregator) for the group defines dependencyManagement for all the
>> child poms so that keeping versions consistent within the group and
>> releasing them together is easy. So far, so good.
>>
>> But other projects might depend on a subset of the group, or have
>> transitive dependencies on them, so I list the whole set of ca.zac.A
>> modules in the dependencyManagement section of each such project: I
>> want to be sure of keeping the versions consistent and known, and
>> sometimes Maven's resolution ends up choosing mixed versions. But
>> adding the whole set means I end up duplicating a large block of the
>> POM in multiple projects. And if I add a new module that might get
>> transitively included, then I have to update multiple places. I am
>> looking for a way to centralize this information.
>>
>> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
>> properties to affect transitive dependencies is not likely to happen
>> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>>
>> 2) The idea of inheriting from the ca.zac.A parent pom worked with
>> maven 2.1.0, but not well for other versions (and it smells bad
>> anyway).
>>
>> 3) I *could* list them all in dependencyManagement in my
>> "organizational parent" pom, with the version controlled by a single
>> property, but then I'd have to update it whenever a new module is
>> added to ca.zac.A. Having such a pom list a sizable set of my
>> projects is probably workable, but it feels like I'm abusing it.
>>
>> 4) Multiple inheritance is not supported nor desired, and I understand
>> that the planned "mixin" capability won't be around until post-3.0. I
>> could have an intermediate parent pom, with just the
>> dependencyManagement entries for my group, but in fact, I have more
>> than one such set. So I'd have to put all such groups in one pom, and
>> update it whenever ca.zac.A or .B or .C have a new module. This is
>> probably my best option, but it still feels less than ideal: I'd
>> rather be able to update a discrete place for each group. In
>> practical terms, this isn't much different than putting it in the org
>> parent, because I'd have to use this as the parent for most projects
>> anyway.
>>
>> Am I stuck for now? Is there some other option I'm just not seeing?
>>
>> What I find myself wishing for is something like the following, and
>> just have it apply to all the artifacts in the group (note that I
>> would only ever want to do it for a groupId that I controlled):
>>
>> <dependencyManagement>
>> <dependencies>
>> <dependency>
>> <groupId>ca.zac.A</groupId>
>> <versionId>${ca.zac.A.version}</versionId>
>> <!-- note no artifactId is listed -->
>> </dependency>...
>>
>> Then in the child POMs I could just specify the ca.zac.A.version
>> property. Is there a reason why something like this is a bad idea and
>> would never happen? Or should I just go ahead and submit a request
>> for it? It looks like there used to be a similar one at MNG-3633
>> (using wildcards), but that JIRA has vanished!
>>
>> Should I just grin and bear it until mixins in 3.1? If so, I'll see
>> if there's some way I can contribute.
>>
>> Zac
>>
>> ---------------------------------------------------------------------
>> 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: how to best manage versions for a large common set of dependencies
Posted by Ron Wheeler <rw...@artifact-software.com>.
This is a common problem in a portal environment or SOA architecture
where many webapps are generated.
We solved this by creating a set of projects that create sets of jars
that group together a bunch of jars into one massive jar.
For example, we have a spring-mysql-hibernate-tomcat project that
creates an aggregated jar with all of the libraries included in this set
of projects.
The POM that manages this project has all the version numbers so the
parent pom of all of the modules only specifies the application version
and the module only depends on our set of aggregated POMs.
If you want to change the version of a Hibernate library you only have
to change it in one place.
The POMs that create individual application artifacts do not know
anything about the version of Hibernate, they only depend on the current
($project.version) version of the application to get all the right bits
and pieces of spring, mysql, hibernate and tomcat.
This really simplifies the management of individual portlets or web
services.
They call on one parent POM that specifies the {$project.version} and
use this variable in the dependency for spring-mysql-hibernate-tomcat,
jsf, CXF, etc.
This means that a module's POM is very stable and only has 4 or 5
dependencies.
We also deploy the aggregated jars into the Tomcat shared library.
This makes the webapps very small and reduces the number of choices that
a developer has to make about third party jars.
Ron
On 24/08/2010 5:54 PM, Zac Thompson wrote:
> I've racked my brain to come up with an ideal solution to this,
> without success, so I'm throwing myself on the mercy of the group.
> Any and all advice is greatly appreciated.
>
> I have a project with many modules that are all released together;
> let's say they're in group ca.zac.A. The parent pom (also the
> aggregator) for the group defines dependencyManagement for all the
> child poms so that keeping versions consistent within the group and
> releasing them together is easy. So far, so good.
>
> But other projects might depend on a subset of the group, or have
> transitive dependencies on them, so I list the whole set of ca.zac.A
> modules in the dependencyManagement section of each such project: I
> want to be sure of keeping the versions consistent and known, and
> sometimes Maven's resolution ends up choosing mixed versions. But
> adding the whole set means I end up duplicating a large block of the
> POM in multiple projects. And if I add a new module that might get
> transitively included, then I have to update multiple places. I am
> looking for a way to centralize this information.
>
> 1) I can see from http://jira.codehaus.org/browse/MNG-3782 that using
> properties to affect transitive dependencies is not likely to happen
> any time soon, and I wholeheartedly agree that it's a bad idea anyway.
>
> 2) The idea of inheriting from the ca.zac.A parent pom worked with
> maven 2.1.0, but not well for other versions (and it smells bad
> anyway).
>
> 3) I *could* list them all in dependencyManagement in my
> "organizational parent" pom, with the version controlled by a single
> property, but then I'd have to update it whenever a new module is
> added to ca.zac.A. Having such a pom list a sizable set of my
> projects is probably workable, but it feels like I'm abusing it.
>
> 4) Multiple inheritance is not supported nor desired, and I understand
> that the planned "mixin" capability won't be around until post-3.0. I
> could have an intermediate parent pom, with just the
> dependencyManagement entries for my group, but in fact, I have more
> than one such set. So I'd have to put all such groups in one pom, and
> update it whenever ca.zac.A or .B or .C have a new module. This is
> probably my best option, but it still feels less than ideal: I'd
> rather be able to update a discrete place for each group. In
> practical terms, this isn't much different than putting it in the org
> parent, because I'd have to use this as the parent for most projects
> anyway.
>
> Am I stuck for now? Is there some other option I'm just not seeing?
>
> What I find myself wishing for is something like the following, and
> just have it apply to all the artifacts in the group (note that I
> would only ever want to do it for a groupId that I controlled):
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>ca.zac.A</groupId>
> <versionId>${ca.zac.A.version}</versionId>
> <!-- note no artifactId is listed -->
> </dependency>...
>
> Then in the child POMs I could just specify the ca.zac.A.version
> property. Is there a reason why something like this is a bad idea and
> would never happen? Or should I just go ahead and submit a request
> for it? It looks like there used to be a similar one at MNG-3633
> (using wildcards), but that JIRA has vanished!
>
> Should I just grin and bear it until mixins in 3.1? If so, I'll see
> if there's some way I can contribute.
>
> Zac
>
> ---------------------------------------------------------------------
> 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