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
Added it to my corporate super pom. No complaints there. But if I try
to run mvn install (mvn2) with the added profile I get an enforcer
error saying that the maven-site-plugin has no version specified. If
I remove the 3.0-beta-1-SNAPSHOT m-site-p from the maven-3 profile the
build works again.
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
It seems the enforcer plugin is set to prevent usage of SNAPSHOT in plugins
even when plugin is defined in a non active profile. I suppose you could open a
JIRA issue about that, but according to me the cleaner way is to use a released
version (or perhaps a locked SNAPSHOT) of m-site-p. If you
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 26 April 2010 12:41, Julien HENRY henr...@yahoo.fr wrote:
It seems the enforcer plugin is set to prevent usage of SNAPSHOT in plugins
even when plugin is defined in a non active profile. I suppose you could
open a JIRA issue about that, but according to me the cleaner way is to use
a
Hi,
I have the following error using Maven 3.0-beta-1. Before trying to reproduce
on a smaller project, could you please have a look and tell me if this is a
known issue. The only similar issue I have found is: MENFORCER-55
$ mvn versions:display-plugin-updates -X
[...]
[DEBUG] final aggregate
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
Known issue...
On 26 April 2010 13:38, Julien HENRY henr...@yahoo.fr wrote:
Hi,
I have the following error using Maven 3.0-beta-1. Before trying to
reproduce on a smaller project, could you please have a look and tell me if
this is a known issue. The only similar issue I have found is:
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
Julien HENRY wrote:
[ERROR] Failed to execute goal
org.codehaus.mojo:versions-maven-plugin:1.1:display-plugin-updates (default-cli)
on project myproject: Execution default-cli of goal
org.codehaus.mojo:versions-maven-plugin:1.1:display-plugin-updates failed.
NullPointerException - [Help 1]
Thanks for the reminder; now that JIRA is back, I need to call a vote
for the javadoc plugin.
Jason, can you try building a snapshot of the javadoc plugin trunk to
see if it solves the problem for you? If so, I'll go ahead and ferry the
release through.
On 4/23/10 2:02 PM, Jason van Zyl
Hi all,
I've been hesitating about posting this to the user list, but since it's
more related to maven3, I put it on the dev list as my very first message
here :).
If I should better have post on the users, please let me know.
I've recently tried to release a small remote-resources project, but
Out of curiosity - how is it possible to cut a release without a
settings.xml file? Don't you *always* need repository credentials? I
guess if your repository was accessed via file://...
Note - This isn't to suggest that this issue shouldn't be resolved.
On 4/26/10 8:30 AM, Baptiste MATHUS
Baptiste MATHUS wrote:
I'm posting here because I don't really know where the bug belongs. Is it to
be considered a mvn3 regression? A release-plugin bug? Something/somewhere
else?
I'll file an issue if necessary where it must be put.
As you already pointed out, the validation of the -s
Could this be slated for beta-2? And if it is decided to be not the
right time, bump it to 3.1?
On Fri, Apr 23, 2010 at 3:19 AM, Benjamin Bentmann
benjamin.bentm...@udo.edu wrote:
Brett Porter wrote:
However, it is important to be able to change the settings.xml file in
future, and the best
On Apr 26, 2010, at 11:43 AM, Paul Benedict wrote:
Could this be slated for beta-2? And if it is decided to be not the
right time, bump it to 3.1?
I think we should focus on fixing issues for 3.0, but that doesn't mean we
can't start thinking and making prototypes for other features.
On
What is the recommended procedure for fixing hash files in a Maven
repo that have the wrong syntax?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3
3B4C
The hash is correct, but not all tools can process the hash when it
Hi,
Well, no. Using SVN, the credentials are stored externally. Or you can even
give them on the command line (-Duser/password).
And btw, we're using svn:// protocol.
Cheers
2010/4/26 Justin Edelson justinedel...@gmail.com
Out of curiosity - how is it possible to cut a release without a
Ah. I forgot about wagon-svn. Thanks for the clarification.
Baptiste MATHUS wrote:
Hi,
Well, no. Using SVN, the credentials are stored externally. Or you can even
give them on the command line (-Duser/password).
And btw, we're using svn:// protocol.
Cheers
2010/4/26 Justin Edelson
Le lundi 26 avril 2010, Brett Porter a écrit :
On 26/04/2010, at 3:08 AM, hbout...@apache.org wrote:
Author: hboutemy
Date: Sun Apr 25 17:08:01 2010
New Revision: 937825
URL: http://svn.apache.org/viewvc?rev=937825view=rev
Log:
removed maven-archetype-mojo since it is superceded by
Use Nexus and run rebuild maven metadata.
On Mon, Apr 26, 2010 at 11:56 AM, sebb seb...@gmail.com wrote:
What is the recommended procedure for fixing hash files in a Maven
repo that have the wrong syntax?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB
What is the recommended procedure for fixing hash files in a Maven
repo that have the wrong syntax?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3
3B4C
The hash is correct, but not all tools can process the hash when
Hi Everyone,
The current behaviour in Maven is that the central repository is built into the
code, and it's there unless you hack your settings.xml to disable it. This can
be a bit confusing when trying to configure your settings for a repository
manager. And it's not immediately clear what
Paul Gier wrote:
Would there be any problems if the central repo definition was moved out of the
Maven internals and into the default settings.xml [1]?
I assume you refer to the global settings file shipped inside the Maven
installation directory. The one issue I know about is that embedders
On Apr 26, 2010, at 6:08 PM, Paul Gier wrote:
Hi Everyone,
The current behaviour in Maven is that the central repository is built into
the
code, and it's there unless you hack your settings.xml to disable it. This
can
be a bit confusing when trying to configure your settings for a
I assume you want to make it easier for people to get the correct
settings? Moving it from the super pom could have unexpected side
effects, but what if we put the default boiler plate[1]
configuration for that into the default settings.xml commented out? I
think this would solve the main
35 matches
Mail list logo
