maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Fabulich <>
Subject Re: Proposal after-the-fact: Experimental multithreading support
Date Tue, 10 Nov 2009 18:53:36 GMT
Jason van Zyl wrote:

> It's not going in that fast.

Fair enough; that seems to be the consensus.

> Sorry, but passing all the existing ITs is the first step and then there 
> is ITs for the feature you multi-threading feature itself.

I've got a couple of ITs for MNG-3004 parallel projects on my machine now 
(just for --fail-never, --fail-fast, --fail-at-end); I'll check them into 
trunk/core-it-suite when the MNG-3004 branch lands.  (Since I'm not sure 
when that is I don't know what version range to apply yet.)

> [snip forward]

> I also don't particularly think it's a good idea without actually 
> thinking about the impact of not doing MNG-2802.

I presume you don't mean just "thinking" about the impact, but testing the 
impact with ITs.

I've already tried temporarily using multithreaded code by default and 
running the ITs on my machine; I think that's a reasonable impact test. 
Is there more testing you have in mind?  If so, what?

> [snip backward]

> You're not experimenting on users.

Just to clarify, do you object to the very idea of having experimental 
features that are disabled by default?

I can pretty well guarantee the safety of the code when the feature is 
off, but it will be a lot of work to guarantee that the feature is safe 
when enabled.  (Indeed, we know it isn't safe right now, due to the 
un-thread-safe local repo.)

But I think that's OK; a certain kind of user will want to type 
"-Dmaven.threads.experimental=8" just to see what happens.  That kind of 
user will want to be part of the experiment.

Does that sound OK?

>> 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.
> Why would the layout have anything to do with thread safety? It should just 
> be threadsafe don't you think?

There isn't much commentary in 
but the bit of discussion that is there suggests that the best solution 
for MNG-2802 would be to implement Brett's proposal from last year:

That seems right to me.

It sounds like you're thinking that we shouldn't do this, but should 
instead just fix the locking behavior in the existing layout?  Why so?


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

View raw message