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
<rwhee...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
