This is more a plan to implement the existing multi-threading patch than an actual proposal. Imo a proposal should describe the solution...ie how will this multi-threading work, how will it decide what to build and in what order, etc. I think essentially the details you Ralph and I briefly discussed at ApacheCon.
On Sat, Nov 14, 2009 at 2:21 PM, Dan Fabulich <d...@fabulich.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
