maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <>
Subject Re: Concurrency in m3 - a status report
Date Mon, 26 Apr 2010 12:40:27 GMT
On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:

> Stephen Connolly wrote:
>> ... but each release of m3
>> would have it's own compatibility info and we would have another state:
>> unknown
>> e.g.
>> <thread-safety>
>>   <plugin groupId="..." artifactId="...">
>>     <wieve-mode action="ban" versions="...">message</wieve-mode>
>>     <wieve-mode action="warn" versions="...">message</wieve-mode>
>>     <wieve-mode action="checked" versions="..."/>
>>     <parallel-mode action="ban" versions="...">message</paralle-mode>
>>     <parallel-mode action="warn" versions="...">message</paralle-mode>
>>     <parallel-mode action="checked" versions="...">message</paralle-mode>
>>   </plugin>
>> </thread-safety>
>> Any plugins not in the list would be "unknown" and the user gets a big fat
>> warning
> Did you also consider the maintainability aspect of such a list? No user wants to see
"big fat warnings" that are irrelevant for their builds so I envision users will either bug
the plugin author or us directly to add plugin X to this list and ask us to roll a new release
of this list such that they get rid of that warning.
> Plugins should be self-describing, that's why mojo annotations and the plugin descriptor
exists. I definitively don't want to see us maintaining the metadata for 3rd party plugins.
> For this reason, I prefer the original suggestion to introduce a new mojo annotation.
Apparently, whatever mojo annotation we come up with, it's not present in any existing plugin
release. Now, for plugins missing the threading anno, what is the safer assumption with respect
to proper build results: That mojo X is thread-safe (when this was never before a concern)
or that it isn't?
> IMHO, there's only way to limit this "oh, I deliberately enabled nitro injection and
now my engine blew up, how am I supposed to know that this is dangerous?": Unless a mojo is
explicitly marked with @threadsafe, issue a warning like

Right. It's pretty simple. If the author has worked on and tested then they can mark the mojo
as such. Otherwise the mojo gets no benefit from the parallel mode.

A @nothreadsafe annotation makes no sense. We're going to go around and mark everyone else's
mojos? That's not going to work and neither is maintaining third party information. If we
start the process of adding the annotation we can easily get the basic mojos in the default
lifecycle annotated accordingly. If we deem this a requirement for the 3.0 release then we'll
work on plugins for a little while before releasing 3.0. 

> "Goal X does not appear to support concurrent execution and might fail the build, use
parallel building at your own risk."
> Benjamin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:



Jason van Zyl
Founder,  Apache Maven

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message