I figured I'd make individual issues on the plugins and commit the
fixes, the plugin issues I've found so far are
reasonably small and I do not see the need for a high-level issue. (As
long as it's trivial stuff I'll just
make these commits without further ado).
We might need some kind of way to tag issues as concurrency problems in
jira, though - because ATM
I will not know if someone makes a concurrency-related fix in a mojo I'm
not watching ? And we really should
have some list of "known good" plugin versions.
I do not have commit access to modello so I cannot fix that.
I will also correct myself before someone arrests me:
Quite simply the mojo's use plexus components that are singletons but the
/plexus components/ contain per-request mutable state
(http://jira.codehaus.org/browse/MODELLO-239).
So the mojo is correct, but there's mutable state in the injected plexus
singleton components.
Kristian
Den 12.04.2010 11:58, skrev nicolas de loof:
Do we have any top-level jira for thread-safety and // build issues ?
I myself got failures in // build with AspectJ plugin
2010/4/12 Kristian Rosenvold<kristian.rosenv...@gmail.com>
I found the bug in the modello plugin that was breaking /any/ build using
modello in multi-modules; and I'm fairly sure the same kind of issue will be
found elsewhere:
Quite simply the mojo's use plexus components that are singletons but the
mojos themselves contain per-request mutable state (
http://jira.codehaus.org/browse/MODELLO-239).
Since we're only a very short time away from beta-1 I just wanted to know
what you think should be done:
A) Treat this as a documentation problem and do maybe just update some mojo
guidelines regarding singleton usage, maybe keep a list of known good
versions.
B) Add some kind of "isThreadSafe" attribute to the mojo metadata that
could be used to assert if the mojo can be run concurrently without warning,
i.e.:
if ( isParallel()&& !isThreadSafe( mojo))
{
logger.warn("Mojo " + mojo + " is not known to be thread safe and may
have issues running concurrently");
}
C) Something else ?
Thoughts ? If B, how should it be done ?
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
