maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Fabulich <>
Subject Re: Testing Kristian's MNG-3004 branch
Date Thu, 07 Jan 2010 02:36:41 GMT
Kristian Rosenvold wrote:

> In this process I removed your original implementation, simply because
> it allowed me to work freely in simplifying my own implementation (and I
> truly believe I managed to make some good simplifications). I also
> considered that I'd re-add your implementation as a third strategy
> when/if needed - it'll only take me an hour or two.

If it'd only take you an hour or two, I suggest we try it.  I can take a 
crack at it if you're busy, but I'm not quite seeing where to plug in at 
the moment.

> as far as I can see it will work for every single project right out of 
> the box

Yes, that would be nice :-)

As for "weave" mode:

> Each ExecutionPlanItem now potentially has a "schedule" attached to it, 
> that describes external requirements that must be met before the item 
> can be executed. This schedule is determined by a declarative 
> representation attached to class "DefaultLifecycles" (method 
> DefaultLifecycles.createExecutionPlanItem).

That sounds more aggressive than what I was imagining.  I was only 
imagining splitting the work into lifecycle phases; if I understand you 
correctly, you're splitting to individual mojo executions, which is much 
more fine-grained.

So I was imagining running the entire compile phase of project X 
sequentially in a thread, concurrent with the compile phase of project Y; 
dependent project Z wouldn't begin compiling until X and Y had finished 
compiling, but X and Y could begin testing while Z was compiling.

It seems like you're splitting the phase up into pieces, too; so 
individual mojos of project X could run concurrently with each other, 
which I was *not* imagining.

The problem with splitting down to the execution item is that then you 
need to know the dependencies between execution items (if any); the 
dependencies need to be expressed in mojo metadata, etc.

But if we only split down to lifecycle phase, well, we know the ordering 
of lifecycle phases, and as long as we run them in that order, we're 
guaranteed correctness, and we don't have to add mojo metadata, right?

(Well, except maybe declaring that certain mojos need to be 

To put names on this, I think there are three "granularities" under 

* Project granularity (my first attempt in the MNG-3004 branch)
* Phase granularity (my intended description of "weave" mode)
* Mojo granularity (your highly concurrent implementation)

(In practice, I think you would have something very close to phase 
granularity just by assuming that every mojo was "output dependent."  Or 
am I misunderstanding?)

> forkable: Means this execution can be forked in an additional thread. 
> This scheduling is the source of the "violate lifecycle" concept, it's 
> the only scheduling that'll allow out-of-order execution of lifecycle 
> phases for a given module. I'm still not sure if this should be present.

I don't quite see the difference; can you describe it with an example?

e.g. if I had a maven-foo-plugin bound to the "test" phase that was marked 
forkable, but my project Z had a dependency on X and Y, when would the foo 
plugin run in "violate lifecycle" mode?  Before X and Y?  Before Z's 
compile was done?

> - Do we need just *one* implementation of concurrency execution
> strategy ?
> I am unsure of this, but personally I feel multiple implementations
> may distract us from reaching a truly great end result. Then again,
> I am personally not able to specify *exactly* what such a truly great
> result consists of. And Dan's implementation does the job safely.

My long-term goal is that Maven should run by default in "concurrent" mode 
where threads = 1; optionally, users can crank up the number of threads 
*without* changing the execution strategy.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message