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

Reply via email to