Processing Order for the m2 Reactor

["Allison, Bob" <ro...@qwest.com>]

I have been looking at the order that the reactor processes projects and
it appears that, unless there is an explicit dependency, processing is
always done from the top down.  I suspect that there are good reasons to
do things that way, but I can think of a couple instances where
processing from the bottom up might be better:
-- A parent project that packages an EAR, where each child project is a
component to be packaged in the EAR, would work better since the parent
project could always be sure that the components are freshly-built
-- The site generation process would be able to pull the
freshly-completed sites from each module during its own processing
without requiring the modules to push up to the parent

I did an experiment to change ReactorManager, line 88, to reverse the
edge between parent and child.  This changes passed all of the
integration tests and did convert the processing to be bottom up.

I'm not sure if this change is a good thing, but it does make the
reactor work in a manner similar to how the 1.x multiproject plugin
operates (but of course with better dependency resolution).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Processing Order for the m2 Reactor

[Brett Porter <br...@apache.org>]

Vincent Massol wrote:

>Cool, I must have missed this new feature. How does it work?
>  
>
Searches ".." (or a directory you can specify in the <parent> element).
If the file exists and versions match, it is used instead. Its the first
step towards a "workspace" style setup where projects know where the
other ones live, taking the repo out of the equation for faster dev.

 -Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Processing Order for the m2 Reactor

[Vincent Massol <vm...@pivolis.com>]

> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: vendredi 19 août 2005 15:40
> To: Maven Developers List
> Subject: Re: Processing Order for the m2 Reactor

[snip]

> >- You can't cd to a module and build it. You need to always build the
> parent
> >first so when you do development you often forget to republish a modified
> >parent POM.
> >
> >
> irrelevant in beta-1

Cool, I must have missed this new feature. How does it work?

[snip]

Thanks
-Vincent


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Processing Order for the m2 Reactor

[Brett Porter <br...@apache.org>]

Vincent Massol wrote:

>I have also been a bit troubled by this too. The issues that I see with a
>parent-build-first strategy are:
>
>- It's the opposite of m1
>  
>
ok

>- You can't cd to a module and build it. You need to always build the parent
>first so when you do development you often forget to republish a modified
>parent POM.
>  
>
irrelevant in beta-1

>- It doesn't work for aggregation when a parent does something on the result
>of the children's build, like aggregating children jars in a uberjar, or
>aggregating javadocs into a single javadoc, etc. Of course, as you mention,
>module traversal features could be implemented every time in the plugin
>itself but doesn't it means reimplementing manually the module discovery in
>each plugin?
>  
>
I still think we need more work on the aggregation. For your ear case,
you want to build each then take the artifacts, but for the javadoc case
you just want to run the root and give it a bunch of source directories
(using the reactor projects to grab source directories).

>This is a complex topic though and there are lots of details to take into
>account. I'm only listing here the issues that I see but I'm pretty sure
>there are other issues too with doing children-build-first. But it does
>sounds more logical to me to start as deep as possible and then work up to
>the top level.
>  
>
Yep, I've put Bob's bug in for beta-1.

>It sounds to me as if POM definitions should be done top-down and builds
>bottom-up...
>  
>
Not necessary, as I mentioned.

Night!

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

RE: Processing Order for the m2 Reactor

[Vincent Massol <vm...@pivolis.com>]

> -----Original Message-----
> From: Brett Porter [mailto:brett@apache.org]
> Sent: vendredi 19 août 2005 12:39
> To: Maven Developers List
> Subject: Re: Processing Order for the m2 Reactor
> 
> so you are saying that the children should build before the parent?
> Currently, the parent is considered a dep so it always goes first.
> 
> I see your point, which would mean making the modules dependencies
> instead of the parent (though anything aggregating really should use
> plugins able to deal with that rather than recursing the subprojects).
> It was deliberately building them first so a pom would be installed at
> the start, but with the built in pom discovery that is no longer
> necessary.
> 
> Anyone else have thoughts?

I have also been a bit troubled by this too. The issues that I see with a
parent-build-first strategy are:

- It's the opposite of m1
- You can't cd to a module and build it. You need to always build the parent
first so when you do development you often forget to republish a modified
parent POM.
- It doesn't work for aggregation when a parent does something on the result
of the children's build, like aggregating children jars in a uberjar, or
aggregating javadocs into a single javadoc, etc. Of course, as you mention,
module traversal features could be implemented every time in the plugin
itself but doesn't it means reimplementing manually the module discovery in
each plugin?

This is a complex topic though and there are lots of details to take into
account. I'm only listing here the issues that I see but I'm pretty sure
there are other issues too with doing children-build-first. But it does
sounds more logical to me to start as deep as possible and then work up to
the top level.

It sounds to me as if POM definitions should be done top-down and builds
bottom-up...

What am I missing (I'm pretty sure I'm missing a lot)? :-)

Thanks
-Vincent

> 
> - Brett
> 
> Allison, Bob wrote:
> 
> >I have been looking at the order that the reactor processes projects and
> >it appears that, unless there is an explicit dependency, processing is
> >always done from the top down.  I suspect that there are good reasons to
> >do things that way, but I can think of a couple instances where
> >processing from the bottom up might be better:
> >-- A parent project that packages an EAR, where each child project is a
> >component to be packaged in the EAR, would work better since the parent
> >project could always be sure that the components are freshly-built
> >-- The site generation process would be able to pull the
> >freshly-completed sites from each module during its own processing
> >without requiring the modules to push up to the parent
> >
> >I did an experiment to change ReactorManager, line 88, to reverse the
> >edge between parent and child.  This changes passed all of the
> >integration tests and did convert the processing to be bottom up.
> >
> >I'm not sure if this change is a good thing, but it does make the
> >reactor work in a manner similar to how the 1.x multiproject plugin
> >operates (but of course with better dependency resolution).
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Processing Order for the m2 Reactor

[Brett Porter <br...@apache.org>]

so you are saying that the children should build before the parent?
Currently, the parent is considered a dep so it always goes first.

I see your point, which would mean making the modules dependencies
instead of the parent (though anything aggregating really should use
plugins able to deal with that rather than recursing the subprojects).
It was deliberately building them first so a pom would be installed at
the start, but with the built in pom discovery that is no longer necessary.

Anyone else have thoughts?

- Brett

Allison, Bob wrote:

>I have been looking at the order that the reactor processes projects and
>it appears that, unless there is an explicit dependency, processing is
>always done from the top down.  I suspect that there are good reasons to
>do things that way, but I can think of a couple instances where
>processing from the bottom up might be better:
>-- A parent project that packages an EAR, where each child project is a
>component to be packaged in the EAR, would work better since the parent
>project could always be sure that the components are freshly-built
>-- The site generation process would be able to pull the
>freshly-completed sites from each module during its own processing
>without requiring the modules to push up to the parent
>
>I did an experiment to change ReactorManager, line 88, to reverse the
>edge between parent and child.  This changes passed all of the
>integration tests and did convert the processing to be bottom up.
>
>I'm not sure if this change is a good thing, but it does make the
>reactor work in a manner similar to how the 1.x multiproject plugin
>operates (but of course with better dependency resolution).
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>
>
>  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org