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 <[email protected]>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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
