What about adding such concurrency metadata aside plugin artifact in local repository, either by extending metadata.xml or using a new concurrency-metadata.xml file ?
In such case users/repo maintainers could easily "tag" plugin as (not) beeing thread-safe 2010/4/26 Stephen Connolly <stephen.alan.conno...@gmail.com> > On 26 April 2010 12:05, Benjamin Bentmann <benjamin.bentm...@udo.edu> > 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 > > > > "Goal X does not appear to support concurrent execution and might fail > the > > build, use parallel building at your own risk." > > > > > Fair enough, but I would also like to be able to annotate a mojo such that > I > explicitly don't want it invoked in parallel and not warn the user (perhaps > explain to the user why certain mojos cannot be executed in parallel) > > -Stephen > > > > > > Benjamin > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > >
