MG2>quick comment below
> Date: Fri, 25 Mar 2016 12:28:37 +0100 > From: christophe.thiebaud@dag.cloud > To: users@maven.apache.org > Subject: RE: AW: Find the correct build order of a set of distinct > butinterdependent projects > > 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 MG>B is a direct dependent of A1MG>B is *not* a direct dependent of AMG>A2 is a direct dependent of A1MG>A2 is also a direct dependent of BMG>so A2 is direct dependent of B where B is a direct dependent of A1? MG>please post examples of of pom.xml for A, A1, (B) and A2 so we can follow your example: > > +------+ > | 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 >
