You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2010/04/06 17:40:42 UTC

// builds for beta 1 (MNG-3004), going for commit

I am going to commit my changes for MNG-3004 to M3 for beta 1. 
The change consists of the following:
  
* A modularization of the DefaultLifecycleExecutor into smaller
components. This is primarily done with the intention of extracting
execution strategy somewhat from the rest of the logic.
// builds for beta 1 (MNG-3004)
* Three differenent execution strategies:
A) Linear ("Classic")
B) Parallel (Based on Dan's original implemementation)
C) Weave (Still experimental) 

The command line -T option activates parallel running, and the argument
is in the form
-T <[nThreads, a float][C][W]|auto>

The C flag scales threads according to CPU cores, this is why nThreads
is a float
The W flag activates weave mode (undocumented)
Examples:
"mvn -T auto install " 
   autoconfigures threads based on cpu count (1 thread per core).
"mvn -T 1.5C install"
   Runs with 6 threads on a 4 core computer.
   Runs with 2 threads on a single core computer.
"mvn -T 1.87CW install"
   Runs with 7 threads weave mode on a 4 core computer.

Better suggestions welcome ;) Bikeshedding opportunities galore ;)

Risks/Consequences
=====
* I'm not particularly worried about functional regressions in Linear
mode, and Parallel mode is also stable.
* This does not mean the full set of maven plugins necessarily works in 
parallel mode; I expect there will be issues with plugins that I have
not uncovered as of yet.
* There is a risk that I have removed some methods from
DefaultLifecycleExecutor that may have to be re-added (if they were not
documented as being externally in-use, I have removed them)
* From a maven-core perspective, I see no reason to flag "parallel" as
experimental.
* Weave mode is still experimental (and is not added to any official
API's - but parallel is). It's clearly pushing close to the limits of
what the JVM handles. I will be extending my testing onto Windows to
check behaviour on different platforms. My goal is to get this stable
before 3.0 final. The modularization of the lifecycle executor ensures
that most further changes will be contained to the single
"LifecycleWeaveBuilder" class (which encapsulates most of "weave" mode).
* Weave mode has some minor issues that are intentionally left TODO,
pending that the overall stability goals can be reached.
* I will be updating surefire to include the parallel->forkmode>=once
check.
* The change includes decent test coverage; no existing its were harmed
and quite a few new unit-tests have been added.  I will elaborate these
even further in the weeks to come.

I'm not calling a vote on this, but now is the time for objections. I
will commit this in about 24 hours time unless there's any significant
objections. The current patch is at
http://github.com/krosenvold/maven3, 
and if nothing else, I know Benjamin will be at it with his microscope
afterwards ;)

The only last thing I'll do now is to read/search through the core
plugins looking for references to methods I have deleted in
DefaultLifecyleExecutor. 

Kristian



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


Re: // builds for beta 1 (MNG-3004), going for commit

Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 6, 2010, at 12:32 PM, Kristian Rosenvold wrote:

>> If you think that in Linear mode you're going to affect the behavior that we have right now that's a bit of a problem. he 
> Sorry if I was unclear. Linear mode is not affected and should be pretty
> much in the clear for future changes too. It's the way we want it.
> 
>>> * From a maven-core perspective, I see no reason to flag "parallel" as
>>> experimental.
>> Until it runs in the wild for a bit I think we have to.
> 
> Yes, it's the correct thing to do no matter what, since the total
> experience is what the user judges by. 
> 

I'm sure folks will try it with a little pushing and blogging. I think we should still maintain the position that 3.0 should be as behaviorally consistent with 2.x as possible. If we can get everyone moved forward then you'll have lots of guinea pigs :-)

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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------


Re: // builds for beta 1 (MNG-3004), going for commit

Posted by Kristian Rosenvold <kr...@gmail.com>.
> If you think that in Linear mode you're going to affect the behavior that we have right now that's a bit of a problem. he 
Sorry if I was unclear. Linear mode is not affected and should be pretty
much in the clear for future changes too. It's the way we want it.

> > * From a maven-core perspective, I see no reason to flag "parallel" as
> > experimental.
> Until it runs in the wild for a bit I think we have to.

Yes, it's the correct thing to do no matter what, since the total
experience is what the user judges by. 

Kristian


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


Re: // builds for beta 1 (MNG-3004), going for commit

Posted by Jason van Zyl <ja...@sonatype.com>.
On Apr 6, 2010, at 11:40 AM, Kristian Rosenvold wrote:

> I am going to commit my changes for MNG-3004 to M3 for beta 1. 
> The change consists of the following:
> 
> * A modularization of the DefaultLifecycleExecutor into smaller
> components. This is primarily done with the intention of extracting
> execution strategy somewhat from the rest of the logic.
> // builds for beta 1 (MNG-3004)
> * Three differenent execution strategies:
> A) Linear ("Classic")
> B) Parallel (Based on Dan's original implemementation)
> C) Weave (Still experimental) 
> 
> The command line -T option activates parallel running, and the argument
> is in the form
> -T <[nThreads, a float][C][W]|auto>
> 
> The C flag scales threads according to CPU cores, this is why nThreads
> is a float
> The W flag activates weave mode (undocumented)
> Examples:
> "mvn -T auto install " 
>   autoconfigures threads based on cpu count (1 thread per core).
> "mvn -T 1.5C install"
>   Runs with 6 threads on a 4 core computer.
>   Runs with 2 threads on a single core computer.
> "mvn -T 1.87CW install"
>   Runs with 7 threads weave mode on a 4 core computer.
> 
> Better suggestions welcome ;) Bikeshedding opportunities galore ;)
> 
> Risks/Consequences
> =====
> * I'm not particularly worried about functional regressions in Linear
> mode, and Parallel mode is also stable.
> * This does not mean the full set of maven plugins necessarily works in 
> parallel mode; I expect there will be issues with plugins that I have
> not uncovered as of yet.

If you think that in Linear mode you're going to affect the behavior that we have right now that's a bit of a problem. I thought the point of this mode was to have almost zero risk while people could experiment with the || and weave options?

> * There is a risk that I have removed some methods from
> DefaultLifecycleExecutor that may have to be re-added (if they were not
> documented as being externally in-use, I have removed them)

I think the ITs will uncover anything pretty quickly. Between you and Benjamin I'm not too worried.

> * From a maven-core perspective, I see no reason to flag "parallel" as
> experimental.

Until it runs in the wild for a bit I think we have to.

> * Weave mode is still experimental (and is not added to any official
> API's - but parallel is). It's clearly pushing close to the limits of
> what the JVM handles. I will be extending my testing onto Windows to
> check behaviour on different platforms. My goal is to get this stable
> before 3.0 final. The modularization of the lifecycle executor ensures
> that most further changes will be contained to the single
> "LifecycleWeaveBuilder" class (which encapsulates most of "weave" mode).

If people don't activate this option it doesn't affect them. I don't think this is a big deal.

> * Weave mode has some minor issues that are intentionally left TODO,
> pending that the overall stability goals can be reached.
> * I will be updating surefire to include the parallel->forkmode>=once
> check.
> * The change includes decent test coverage; no existing its were harmed
> and quite a few new unit-tests have been added.  I will elaborate these
> even further in the weeks to come.
> 
> I'm not calling a vote on this, but now is the time for objections. I
> will commit this in about 24 hours time unless there's any significant
> objections. The current patch is at
> http://github.com/krosenvold/maven3, 
> and if nothing else, I know Benjamin will be at it with his microscope
> afterwards ;)
> 
> The only last thing I'll do now is to read/search through the core
> plugins looking for references to methods I have deleted in
> DefaultLifecyleExecutor. 

I say go for it. We're not in a dire rush and Stuart is also working on getting the core working on Guice so you and Stuart should coordinate as I think you might have some overlapping bits. Once it's all in, if the ITs all pass I'm pretty confident at this point that they model reality to a high degree.

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

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
----------------------------------------------------------