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 visibil
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
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
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 orde
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 i
Use Nexus and run rebuild maven metadata.
On Mon, Apr 26, 2010 at 11:56 AM, sebb 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 52F3
>
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=937825&view=rev
> > Log:
> > removed maven-archetype-mojo since it is
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
Out o
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
> Out of curiosity - how is it possible to cut a release without a
> settings.xml file? Don't y
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
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.
>
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
wrote:
> Brett Porter wrote:
>
>> However, it is important to be able to change the settings.xml file in
>> future, and the best way to do that and st
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 argume
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 wrot
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
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 wrot
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]
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
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 marke
On 26 April 2010 13:40, Jason van Zyl 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.
> >>
> >>
> >>
> >>
Known issue...
On 26 April 2010 13:38, Julien HENRY 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: MENFORCER-55
>
>
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.
>>
>>
>>
>> message
>> message
>>
>> message
>> message
>>
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 26 April 2010 12:41, Julien HENRY 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 released version (
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 Apr
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 c
On 26 April 2010 12:05, 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.
>>
>>
>>
>> message
>> message
>>
>> message
>> message
>> messa
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.
I
Stephen Connolly wrote:
... but each release of m3
would have it's own compatibility info and we would have another state:
unknown
e.g.
message
message
message
message
message
Any plugins not in the list would be "unknown" and the user gets a big fat
w
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 it's
>
>
> 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;
>
> org.codehaus.plexus:p
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 bi
I agree that a @NotThreadSafe annotation is the best way to go.
On 26 April 2010 09:13, nicolas de loof 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
>
> 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 w
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,
35 matches
Mail list logo