Den 26.04.2010 04:02, skrev Igor Fedorenko:
I am sorry if this has been answered already, but do you have any info
that shows performance comparison single vs milti threaded build? If you
happen to have any profiler snapshots that show where time is spent
during single and multi threaded builds,
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
I agree that a @NotThreadSafe annotation is the best way to go.
On 26 April 2010 09:13, nicolas de loof nicolas.del...@gmail.com 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
Den 26.04.2010 10:13, skrev nicolas de loof:
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
The issue is http://jira.codehaus.org/browse/MNG-4642, and as an
alternative solution we could
simply make a list somewhere that blacklists/whitelists/greylists plugins,
as long as there's a reasonable
way to update such a list. Maybe something enforcer-like;
Which implies that it should be a versioned file
Sounds like a jar with a resource containing the parallel compatibility
info
We'd have to maintain it versioned and perhaps provide some system
property to ovrerride the version via settings.xml... but each release of m3
would have
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
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
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
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
On 26 April 2010 13:40, Jason van Zyl ja...@sonatype.com 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
Den 26.04.2010 14:40, skrev Jason van Zyl:
On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
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
On Apr 26, 2010, at 9:09 AM, Kristian Rosenvold wrote:
Den 26.04.2010 14:40, skrev Jason van Zyl:
On Apr 26, 2010, at 7:05 AM, Benjamin Bentmann wrote:
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
I am sorry if this has been answered already, but do you have any info
that shows performance comparison single vs milti threaded build? If you
happen to have any profiler snapshots that show where time is spent
during single and multi threaded builds, I am interested to see these too.
PS: we
14 matches
Mail list logo
