On 11/01/2011 4:33 AM, Anders Hammar wrote:
Your aggregating pom is just a kind of helper project which holds all
modules you want to build. Normally, it shouldn't include any dependencies
(unless you make it a parent pom as well). In any case, it should most
definitely not have a dependency to any of the artifacts it's building.
If you want to create a fifth module with a good name, which declares a
dependency to all the other four artifact projects. However, I don't really
see the need (Ron might disagree here).
4 might not be worthwhile but if you are building anything significant
you can get to 50 pretty quickly with Spring, persistence, databases,
MS-Office integration, JSF, webservices, reporting libraries plus all
the nice little Apache Commons tools.
We did the aggregation to eliminate multiple versions of common
libraries and centralize control over versions so that the developers
did not have to guess what version to use each time they updated a project.
Our application is designed in a very modular way with web services that
provide functions in narrow areas - contract administration is separate
from employee administration, so we have lots of projects that deal with
specific areas.
In my opinion, to benefit from
Maven's dependency management you should declare your direct dependencies
(and only those). By doing so, you will be able to get accurate information
of all artifacts' dependencies. If you include incorrect dependencies, or
rely on transitive dependencies, this will be incorrect.
Also, in your case, I would assume that the user's would only need a
(direct) dependency to one or two of your artifacts. Those should have good
names like xxx-api and xxx-impl (for example).
Good names are important and these are good choices
We also add xxx-libraries to gather together the library projects that
are specific to the application but are shared between modules.
We also have a util-libraries that pulls together the application
independent libraries that we have built (reporting framework, messaging
framework, etc.) to support various projects.
The other ones will be pulled
in as transitive deps. Documentation (a Maven site? A wiki?) is the key.
/Anders
On Mon, Jan 10, 2011 at 18:16, Leon Rosenberg<rosenberg.l...@gmail.com>wrote:
Hi,
so I have 4 projects with one aggregator pom and it works just fine
for publishing and releasing.
I have an aggregator pom, which includes a,b,c,d and it all got built
and stuff.
Now, if a user of mine wants to use this project, he has to know which
of the a,b,c,d modules he actually need, or which is the one, that
includes the other. I thought I could save the user the searching and
let him just declare the dependency to the aggregator pom, but it
obviously don't work (cause maven tries to download the aggregator.jar
and not the transitive dependencies).
Now for the question, what is the best practice here?
Is defining a module with a sounding name, like
the-module-you-have-to-include-in-yourpom which is simply a pom,
defining dependencies to a,b,c,d and which can be used for transitive
resolution, the way to go, or is there another practice?
thanks in advance
Leon
---------------------------------------------------------------------
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
