I agree that a @NotThreadSafe annotation is the best way to go. On 26 April 2010 09:13, nicolas de loof <[email protected]> wrote:
> > > > Plugins > > ========= > > I have only managed to find "real" concurrency problems in the EAR > > plugin and modello as of yet. Modello is fixed in trunk, ear is > > not started AFIK. > > > > All the other stuff I've seen in the core plugins relate to the > > plexus-issues. > > > > Our jira issue is from a user who's complaining about plugins not > > working, and I think he's somewhat right in that we have to make some > > kind of system to indicate compatibility with the -T option. > > > > Although several strategies may be recommended, my personal favourite > > is to make a @threadsafe javadoc annotation and make M3 core > > COMPLAIN LOUDLY about plugins that are unmarked, then proceed as > > requested (i.e. complain but still run threaded). > > > > The problem with these things is that thread safety is not necessarily a > > constant, and in the next 9 months there will be issues. So for some > > plugins @threadsafe might equally much express an intent as much as it > > reflects reality. So that makes me a bit sceptical to @threadsafe too. > > > > > +1, I can't see any way to ENSURE a plugin is threadsafe as it depends on > project and (maybe overriden) plugin dependencies. We can just tag a > plugin > to be expected to work fine in multithreaded context > > I'd suggest to get a @NotThreadSafe annotation for plugins that are KNOWN > to > not be thread safe, mostly due ti the embedded tools. I got > ConcurrentModification issues with aspectJ plugin, so I don't think any > AJC-based plugin could work fine with // build. > > I don't know the way the weave mode is expected to work, but it could maybe > support such @NotThreadSafe plugins by locking concurrent execution of the > same plugin, but still runing other ones/othe phases in // modules. > > > > > Aggressively displaying the link to the wiki page containing the > > most up-todate threading info may be an equally good solution; maybe > > even adding a WARNING: Experimental or something to the build output. > > > > +1 > As we can't make the world thread safe, let the user know what's possible > and how to tweak the build. > > > > > > > > http://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in > > +Maven+3 (if it's up), should contain all the information needed on > > which plugins are known to have issues. But as we all know, it's an open > > ecosystem. > > > > Documentation > > ============ > > I will keep the wiki page updated, provided cwiki.a.o actually stays > > up ;) > > I will add a section on mojo threading models/threading concerns to the > > mojo api specification. > > > > > > I think we have to take some extra measures to keep users out of the > > issue trackers on this one, or at least make sure they go to the right > > place. > > > > What do you think ? > > > > Kristian > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
