On 26 April 2010 13:40, Jason van Zyl <[email protected]> wrote: > 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. > > This is not an @nothreadsafe annotation I was suggesting, but a @noparallel annotation
i.e. for the plugin author to mark a mojo as specifically banning parallel execution -Stephen > > "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: [email protected] > > For additional commands, e-mail: [email protected] > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > >
