On 5 Nov 07, at 11:20 PM 5 Nov 07, Brian E. Fox wrote:
I don't completely agree that non unique should be essentially killed.
Unless you are letting people pin to a specific snapshot instance,
(which IMO is much worse) there are no problems using the non unique
stuff. We switched to it because
I don't completely agree that non unique should be essentially killed.
Unless you are letting people pin to a specific snapshot instance,
(which IMO is much worse) there are no problems using the non unique
stuff. We switched to it because we were using up over 300gb / week from
our continuous inte
On 06/11/2007, at 4:42 PM, Jason van Zyl wrote:
They die.
How that non unique stuff creep in should be looked at. As a short
term convenience for not having to wipe stuff out is far less
important in that you can hose an entire team. Most people nuke the
snapshots after a couple weeks bu
They die.
How that non unique stuff creep in should be looked at. As a short
term convenience for not having to wipe stuff out is far less
important in that you can hose an entire team. Most people nuke the
snapshots after a couple weeks but in that period no one can lock down
to anything
What about non-unique-versioned snapshots?
- Brett
On 06/11/2007, at 4:23 PM, Jason van Zyl (JIRA) wrote:
The deployer should detect previous deployments of the same version
and die if that's the case.
--
---
For 2.1 maybe we should just decide to use 2.1. By the time it comes
out people will be using 1.6.
I think 2.0.x should stay at 1.4 but I think we can safely use 1.5 for
2.1.
On 5 Nov 07, at 6:42 PM 5 Nov 07, John Casey wrote:
Maybe we should generalize that utility into maven-shared or
Maybe we should generalize that utility into maven-shared or
something? I'm guessing this is the sort of problem that could come
up time and again with plugin work, so a piece of common
infrastructure to do this sort of conversion might be a good idea.
-john
On Nov 5, 2007, at 8:56 PM, Bre
It's coming back to me now :) We see this a lot in surefire - for
that reason there's a util class in there to support converting the
classloader URLs on JDKs back to 1.3.
- Brett
On 06/11/2007, at 12:40 PM, John Casey wrote:
Well, I guess that means the ClassLoader.getResource(..) method
Well, I guess that means the ClassLoader.getResource(..) method doesn't
always return RFC 2396-compliant URLs, then...because there's definitely a
space in the returned URL, and the URI construction definitely fails prior
to this change. MNG-3272 details the error I was working with when I made
thi
For more info
I was using the URL.toURI method but it's only available in java 5
http://java.sun.com/javase/6/docs/api/java/net/URL.html#toURI()
"This method functions in the same way as new URI (this.toString()).
Note, any URL instance that complies with RFC 2396 can be converted to
a URI. Howev
cool, thanks
On 06/11/2007, at 11:52 AM, John Casey wrote:
I tried several different ideas (actually, I used the unit test to
try out various strategies), and this is the best thing I could
come up with at the time. Since spaces in file paths is about the
only weird character I've heard ab
I tried several different ideas (actually, I used the unit test to
try out various strategies), and this is the best thing I could come
up with at the time. Since spaces in file paths is about the only
weird character I've heard about in connection with these sorts of
problems, I figured it
Will this fall over on any other characters? ISTR there being a
standard way to get a proper file URL reference for these
occurrences, but it's slipping my mind right now...
On 06/11/2007, at 8:40 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Mon Nov 5 13:40:11 2007
New Revision: 5921
Hi,
I'd like to release maven-source-plugin 2.0.4.
This fixes a couple of minor issues.
The last release was made 6 months ago.
Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11147&styleName=Html&version=13442
Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/m
I must have missed that thread. It wasn't working in the enforcer so I'm not
sure.
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Monday, November 05, 2007 11:25 PM
To: Maven Developers List
Subject: Re: XML encoding, Maven and plugins
Hi Brian,
As requested by
Hi Brian,
As requested by Carlos (and nobody else replied), I copied the XML encoding
classes to the plugins to avoid upgrading the prerequisite. It's only a
workaround to try to maintain low prerequisite.
Do you mean that such a workaround isn't working properly?
If nobody is against upgrading
Brian,
If you have a prereq of maven 2.0.6, can you still use maven-core:2.0.7?
[EMAIL PROTECTED] wrote:
Author: brianf
Date: Mon Nov 5 04:52:04 2007
New Revision: 591980
URL: http://svn.apache.org/viewvc?rev=591980&view=rev
Log:
encoding changes require new p:u and thus maven > 2.0.6
Modifi
Herve,
Any of the plugins that were changed need to have a prerequisite on maven 2.0.6
because they need a new plexus-utils. I found and fixed this already in
enforcer.
--Brian
-Original Message-
From: Hervé BOUTEMY [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 11:44 PM
T
Hello,
I'm researching wether it would be possible to get the emacs flymake
facility working with maven.
Basically this involves having maven compiling a single file and
outputing errors that will be parsed by flymake.
It doesnt appear immediately possible, so my question is: how
difficult would
19 matches
Mail list logo
