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