On 2016-03-22 22:24, Christophe Thiebaud wrote:
Hi all,
for those interested, I stumbled on a (natural) defect with the approach
"#2 "super" multi-module pom" (cf.
http://dag.cloud/docs/theproblem.html)
e.g.
let A and B be 2 projects that need ordering
let A be itself a multi-module project with sub-modules A1 and A2
dependencies are as follow :
A1 no dependency
B depends on A1
A2 depends on B
A2 depends on A1 as well, this is not required for the sake of the
demonstration, but is the common real-life situation
+------------+
| A |
| +----+ |
| | A1 <---+----+
| +--^-+ | ^
| ^ | +-^-+
| ^ | | B |
| ^ | +-^-+
| +--^--+ | ^
| | A2 >--+----+
| +-----+ |
+------------+
"super" multi-module pom will validate fine, no cycle: A1, then B, then
A2
but a cycle exists between A and B projects. no ordering is possible
+------+
| A |
| <----+
| | ^
| | +-^-+
| | | B |
| | +-^-+
| | ^
| >----+
+------+
this defect is not a really a blocker, but some cycle detection logic
needs to be added somewhere in the global solution.
just FYI, thanks!
Christophe
On 2016-03-22 17:01, Martin Gainty wrote:
CT>quick answers prefixed by CT>
MG>quick question prefixed by MG>
Date: Tue, 22 Mar 2016 09:53:33 +0100
From: christophe.thiebaud@dag.cloud
To: users@maven.apache.org; d...@maven.apache.org
CC: e...@zusammenkunft.net
Subject: Re: AW: Find the correct build order of a set of distinct
butinterdependent projects
(sorry for the resend)
Hi Bernd and Elliot,
thanks for the feedback. Happy to know from Elliot that "multi-module
pom generation" has been a viable solution for him. And I must
definitely have a look at how Jenkins Maven Jobs may fit in the
picture, as suggested by Bernd.
Hi maven developers,
I take the liberty to forward this thread to the developer list, in
the hope to get further insights from specialists.
quick summary is here : http://dag.cloud/docs/theproblem.html
Thanks!
Christophe
> On 2016-03-16 00:21, Bernd Eckenfels wrote:
>> Hello,
>>
>> It might not completely solve your problem (as it does not observe
>> versions) but with Jenkins Maven Jobs it builds dependent jobs
>> automatically.
>>
>> If you follow a release strategy it is however not something you need
>> in practice as you have to step through the dependencies to release
>> them anyway.
>>
>> And when your system matures and you start to refacture dependencies
>> they start to change over time.
>>
>> Maybe stuffing all in a graph database would help you (jqassist.org).
>>
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>>
>> Von: Elliot Metsger
>> Gesendet: Dienstag, 15. März 2016 23:27
>> An: Maven Users List
>> Betreff: Re: Find the correct build order of a set of distinct
>> butinterdependent projects
>>
>> 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 <
>> christophe.thiebaud@dag.cloud> 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 :
>>> http://dag.cloud/docs/theproblem.html
>>>
>>> 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 ?
MG>maven-dependency-plugin version 2.8 fixed the issue
MG>https://issues.apache.org/jira/browse/MDEP-407
CT> thanks for the info! So using dependency plugin for the task is
safe.
MG>please confirm
CT> not sure to understand what I should confirm. I am investigating
the possible solutions and did not yet start anything with the
dependency plugin.
CT> Furthermore, as I have now a rough on the edges but working
solution using a mix of super-pom with modules and event spy, I will
likely not start to implement the dependency plugin way.
MG Tangent>curious why you need to combine eclipse and maven
environments?
CT> I do not need to combine eclipse and maven. I only remembered
there had been some issue, I did not remember the context.
CT> I thank you for the clarification
>>> Thanks!
>>> Christophe
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-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
