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
synchronized...?)
To put names on this, I think there are three "granularities" under
consideration:
* 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.
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
