This is now an official proposal here:
http://cwiki.apache.org/confluence/display/MAVEN/Experimental+Multithreading+Support
(I didn't have karma to edit this page until a few minutes ago; you might
need to request karma as well, especially since this the first proposal
in this new location.)
-Dan
Dan Fabulich wrote:
On Friday I was playing cowboy with my experimental thread support, but
here's a more formal proposal around parallel project support in Maven 3.0.
OUTSTANDING ISSUES
In my earlier revision 833566, I attempted to fix MNG-3004:
"Allow build lifecycle to execute projects in parallel"
http://jira.codehaus.org/browse/MNG-3004
The general consensus around this bug (which has 25 votes) is that
multithreading support can't work correctly right now because of MNG-2802:
"Concurrent-safe access to local Maven repository"
http://jira.codehaus.org/browse/MNG-2802
Several people have remarked in comments to MNG-3004 that it's appropriate to
try to fix MNG-3004 (parallel projects) without fixing MNG-2802 (thread-safe
local repo). In doing so, we'll allow users to optionally enable building
multiple projects simultaneously. This is worth doing, because it can be
tested in the wild, and because for some users, it will be immediately useful
(e.g. especially if you use --offline mode).
I agree with these comments, and attempted to implement them in revision
833566.
MY PROPOSAL
I attempted to check in the code in time for 3.0-alpha-3 a few days ago. That
code was rolled back over the weekend and now lives in the MNG-3004 branch,
because it broke integration tests. All integration tests now pass on my
machine with the MNG-3004 branch, so I'd like to land it back in trunk again
and re-cut 3.0-alpha-3 with this additional feature.
As I stated on Friday, using the MNG-3004 branch, you can now do this:
mvn install -Dmaven.threads.experimental=4
It works on my machine. If it works for you great; if it doesn't, we can
figure out what's wrong together.
WHY ALPHA-3?
I'd like to land it back in alpha-3 because:
* alpha-2 was in February; I don't want to wait for even four months to start
testing this in the wild
* I did check it in before alpha-3 was released, but it was rolled back
quickly before the release vote was called
* Otherwise I'd want to try to release alpha-4 immediately after alpha-3,
which seems wasteful
A NOTE ABOUT DEFAULTS
Currently the code defaults to maven.threads.experimental=1. This fires up a
single executor thread who does all work; the main thread joins to wait for
it to finish. It's also possible to set maven.threads.experimental=0, in
which case everything is done on the main thread, just like in alpha-2.
If there is consensus, I'd be happy to set the default value to 0, though
that increases the risk that the multithreaded code will get less coverage in
the wild. I think leaving the value at 1 is a good compromise between
avoiding complex threading issues and exercising tricky code.
WHAT'S IN THE FUTURE?
Post alpha-3 I'm keen on implementing a settings.xml option allowing users to
configure their local repository layout. This will allow users to choose an
alternate implementation that is thread-safe.
Additionally, I think that this feature needs more tooling to make parallel
projects understandable. The logger should be enhanced to identify which
projects are logging which messages, and the final output of Maven should
report more clearly which projects had warning/error messages, and how many
such messages were reported.
What do you say?
-Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
