+1
Emmanuel
Jason van Zyl a écrit :
Hi,
The impetus for this is wanting to release the surefire plugin that has
a tiny bug in it. We are versioning our Maven release major.minor.micro
so why don't we do the same with our plugin and treat everything like
we're going to do small incremental r
+1
Emmanuel
Carlos Sanchez a écrit :
anything pending to do in the apache pom? there are some mistakes in
the version 3 like organization name that propagates to all apache
projects.
-
To unsubscribe, e-mail: [EMAIL PROTECT
+1
Arnaud
On 3/1/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote:
+1
- Joakim
Carlos Sanchez wrote:
> anything pending to do in the apache pom? there are some mistakes in
> the version 3 like organization name that propagates to all apache
> projects.
>
---
+1
Arnaud
On 3/2/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
The impetus for this is wanting to release the surefire plugin that
has a tiny bug in it. We are versioning our Maven release
major.minor.micro so why don't we do the same with our plugin and
treat everything like we're going t
Yup, I think that's the general consensus, though we do need to sift through
the various WAGON* jira projects, and determine what existing issues must be
fixed for a 1.0 release, I suppose.
In a way, it's not made things simpler to break up the different wagons into
separate jira projects...as fa
Patrick & Mike took this over. To be honest, I really don't know what
they are doing. I think they are confused over your desire to have this
be "just the way it works" in 2.1. That means the override tag won't be
there in 2.1. However, it has to be there in 2.0.x to preserve
compatibility.
Hey Ralph/Patrick/Mike,
I see the tree in the sandbox that corresponds to trunk, but is there
one for the branch or is it pretty much the same in both?
Thanks,
Jason.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additi
+1
On 3/2/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
The impetus for this is wanting to release the surefire plugin that
has a tiny bug in it. We are versioning our Maven release
major.minor.micro so why don't we do the same with our plugin and
treat everything like we're going to do smal
I'm interested in helping out in whatever way that I can. I've been
writing enterprise Java about 7 or 8 years now. I think that I could
provide some value to the team. How do I get started?
--
Barry Egbert
[EMAIL PROTECTED]
On 1 Mar 07, at 10:10 PM 1 Mar 07, Brian E. Fox wrote:
Alphas and betas happen before a stable stream. So we have 2.0.4,
2.0.5, but as we progress toward 2.1 we will have 2.1-alpha-1 ...,
2.1-beta-1 ..., then 2.1.0, 2.1.1 and so on.
Jason.
How will alpha and beta releases be handled?
---
+1
(I was going to do that with the 2.3 release, except that it had had
junit4 support added).
Aesthetically, I prefer to drop the trailing 0 on a first point
release, but don't mind either way as long as we're consistent.
- Brett
On 02/03/2007, at 10:20 AM, Jason van Zyl wrote:
Hi,
T
+1
On 3/1/07, Eric Redmond <[EMAIL PROTECTED]> wrote:
+1
standardize 'em
On 3/1/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
>
> +1
>
> I'm running into the same thing with the remote-resources. A one line
fix
> shouldn't be a whole +0.1.
>
> Dan
>
>
> On Thursday 01 March 2007 21:20, Jason
Hopefully there won't be anymore! Please!
I think the alpha/beta not-so-stable releases should be a thing of the
past and avoided altogether. If code's not ready to be released, then
don't release it.
-Nathan
On 3/1/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
How will alpha and beta releases b
+1
standardize 'em
On 3/1/07, Daniel Kulp <[EMAIL PROTECTED]> wrote:
+1
I'm running into the same thing with the remote-resources. A one line fix
shouldn't be a whole +0.1.
Dan
On Thursday 01 March 2007 21:20, Jason van Zyl wrote:
> Hi,
>
> The impetus for this is wanting to release the
How will alpha and beta releases be handled?
-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 01, 2007 9:21 PM
To: Maven Developers List
Subject: [vote] Trying to use standard versioning
Hi,
The impetus for this is wanting to release the surefire pl
Sure thing.
Jason.
On 1 Mar 07, at 9:58 PM 1 Mar 07, Brett Porter wrote:
I don't believe so, but it's not exactly the best class for
'documented behaviour'. I'd say it'd be better to be safe than
sorry and throw in the extra null check.
On 02/03/2007, at 10:37 AM, Jason van Zyl wrote:
I don't believe so, but it's not exactly the best class for
'documented behaviour'. I'd say it'd be better to be safe than sorry
and throw in the extra null check.
On 02/03/2007, at 10:37 AM, Jason van Zyl wrote:
On 1 Mar 07, at 9:23 PM 1 Mar 07, Brett Porter wrote:
was the NPE junitArti
Issue Subscription
Filter: Design & Best Practices (37 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
http://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
htt
On 1 Mar 07, at 9:23 PM 1 Mar 07, Brett Porter wrote:
was the NPE junitArtifact, or baseVersion?
Project with no tests and no reference to junit at all, no
junitArtifact. If there was an artifact could the base version be null?
Jason.
- Brett
On 02/03/2007, at 10:09 AM, [EMAIL PROTECT
+1
I'm running into the same thing with the remote-resources. A one line fix
shouldn't be a whole +0.1.
Dan
On Thursday 01 March 2007 21:20, Jason van Zyl wrote:
> Hi,
>
> The impetus for this is wanting to release the surefire plugin that
> has a tiny bug in it. We are versioning our Maven
was the NPE junitArtifact, or baseVersion?
- Brett
On 02/03/2007, at 10:09 AM, [EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Thu Mar 1 18:09:47 2007
New Revision: 513588
URL: http://svn.apache.org/viewvc?view=rev&rev=513588
Log:
SUREFIRE-300 Fixing the NPE for cases where projects have no t
Hi,
The impetus for this is wanting to release the surefire plugin that
has a tiny bug in it. We are versioning our Maven release
major.minor.micro so why don't we do the same with our plugin and
treat everything like we're going to do small incremental releases
like we should be doing. I
+1
- Joakim
Carlos Sanchez wrote:
> anything pending to do in the apache pom? there are some mistakes in
> the version 3 like organization name that propagates to all apache
> projects.
>
-
To unsubscribe, e-mail: [EMAIL PROTEC
+1
Carlos Sanchez skrev:
anything pending to do in the apache pom? there are some mistakes in
the version 3 like organization name that propagates to all apache
projects.
--
Dennis Lundberg
-
To unsubscribe, e-mail: [EMAIL
So are we pretty much agreed that most things Joakim brought up will
be slated for 1.1/2.0 and we'll push a release of this out as soon as
we can?
Jason.
On 27 Feb 07, at 5:23 PM 27 Feb 07, John Casey wrote:
Hi,
I just committed some changes to trunk that should restore backward
compatibi
On 28 Feb 07, at 11:29 AM 28 Feb 07, Brett Porter wrote:
I think these problems are more often misconfigurations of Maven
(due to it being hard to do) - so something to be fixed in maven by
moving the repo permissions into the project repo definition.
I believe once configured correctly it
+1
On 1 Mar 07, at 12:22 PM 1 Mar 07, Carlos Sanchez wrote:
anything pending to do in the apache pom? there are some mistakes in
the version 3 like organization name that propagates to all apache
projects.
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
anything pending to do in the apache pom? there are some mistakes in
the version 3 like organization name that propagates to all apache
projects.
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
-
Using current sources patched for JBoss, I can't access the configuration
page. As the administrator, when I try to go there, I get the message
Authorization Error You are not authorized to access this page. Please
contact your administrator to be granted the appropriate permissions.
Hi,
I am currently developing some mojos to improve our build and I am a
little bit confused between two parameters that can be set in a mojo:
- ${executedProject}
- ${project}
What is the difference between them? I have read that the executed
project has something t
Trygve Laugstøl wrote on Thursday, March 01, 2007 12:11 PM:
> Jörg Schaible wrote:
>> Dan Tran wrote:
>>
>>> I think you broke the convention of 2 spaces indentation for xml
>>> file ;-)
>>
>> Well, no. All the lines had tab indention except the new ones I
>> added. So I converted them into tab
Jörg Schaible wrote:
Dan Tran wrote:
I think you broke the convention of 2 spaces indentation for xml file ;-)
Well, no. All the lines had tab indention except the new ones I added. So I
converted them into tabs also ;-)
The convention is 2 spaces as indent so please fix the previous
devel
32 matches
Mail list logo
