maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elliot Metsger <>
Subject Re: Find the correct build order of a set of distinct but interdependent projects
Date Tue, 15 Mar 2016 22:27:02 GMT
Hi Christophe,

Just chiming in with my experience; we used to have a complex build, and I
used approach #2.  I don't remember the total number of projects in the
reactor (it was less than 100 for sure, but probably more than 20), and
that worked fine.

I wasn't aware of the Maven event spy approach.  That sounds like a tidy,
albeit more technical, solution.  I don't think we were able to
successfully use the dependency plugin, but this was a few years ago and
the plugin may have advanced since then.

On Tue, Mar 15, 2016 at 4:17 PM, Christophe Thiebaud <> wrote:

> Hi all,
> The problem is all in the title :
> How to find the correct build order of a set of distinct but
> interdependent projects.
> Distinct means that each project lives in its own source repository, each
> project build separately.
> Interdependent means that projects may be dependent upon each other.
> So the question is:
>    - which projects depends on which other projects?
> in order to be able to build the projects still separately, but in the
> correct order.
> e.g. slf4j and logback: which one depends on the other? Which one do I
> need to build first?
> I thought of the following four possible solutions, and I have experience
> with the first three:
> 1. The poor man’s solution : hardcode the order
> 2. Generate a multi-module pom file that contains all projects as modules
> 3. Collect build-time repository events with a maven event spy
> 4. Collect pom file dependency information with the dependency plugin
> to avoid a loooong mail, the options are further detailed here :
> This is so generic a problem that I am sure you've already been faced with.
> I'd be glad to get some piece of advice from the community.
> For instance, is somebody aware of any existing open source toolset around
> this problem?
> Concerning option #4, I am under the impression (from blurred remember of
> some mail exchanges on this list long time ago) that the dependency-plugin
> tree goal implementation is not congruent with the actual aether
> implementation, which, if true, would be a show stopper. Can somebody
> confirm/infirm ?
> Thanks!
> Christophe
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message