Until I see a definitive list of the Milestones for 2.1, I vote for #2.
I am mostly afraid of going down the rat hole that was the old 2.1 with
forever changing scope. I don't see any problem with calling this 2.1
and putting in the other features into 2.2, what's the problem?
-Original Messag
Whether it's 2.1 or 2.2, I'll cover what I know here.
On 29/08/2008, at 8:28 AM, John Casey wrote:
- Dan's reactor changes
- Parallel downloads
- PGP stuff
- MNG-624 and related issues/feature enhancements (parent
versioning, right?)
What I don't know is what state of maturity each of these
heh, I think you just went and changed my mind. :)
Good point!
Either way the vote goes this is a good reason to keep pushing along
with small feature sets.
- Brett
On 30/08/2008, at 1:55 AM, Wendy Smoak wrote:
On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED]
> wrote:
I wou
+1 to #1 (we can always re-release it as 2.1.0 soon after if that
seems better).
No objection if we go with #2 either.
Concrete opinions:
* We should only be maintaining two 2.x branches (one bugfixes, one
for features), no more. We need to get them all back into compilable/
IT-passing stat
Thanks for this Benjamin.
Vincent
2008/8/29 <[EMAIL PROTECTED]>:
> Author: bentmann
> Date: Fri Aug 29 14:06:00 2008
> New Revision: 690389
>
> URL: http://svn.apache.org/viewvc?rev=690389&view=rev
> Log:
> [MNGSITE-48] Consolidate coding pitfalls into a standalone document
>
> Added:
>maven
Hi Benjamin,
[SNIP]
> Is that doing something else than
>
> PluginUtils.sortMojos( mojoDescriptors )
>
> from line 409? I guess one of these is superfluos.
I didn't remember that we have this method!
I will revert part of this commit.
Cheers,
Vincent
>
> Benjamin
>
> ---
Maven 1 ? Ohh no, not it !
On Fri, Aug 29, 2008 at 6:36 PM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
> I think m1 is more concrete than a beta, while signalling that it's not
> feature complete
>
> Sent from my iPod
>
>
> On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <[EMAIL PROTECTED
+1
Arnaud
On Fri, Aug 29, 2008 at 3:33 PM, Daniel Kulp <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Dan
>
>
> On Friday 29 August 2008 5:13:41 am Mark Hobson wrote:
> > 2008/8/27 Mark Hobson <[EMAIL PROTECTED]>:
> > > 2008/8/26 Olivier Lamy <[EMAIL PROTECTED]>:
> > >> +1 (in the future could you provi
a quick aside... I have some ideas for enforcer rules that should end
up in m-e-p by default
is mojo.codehaus.org a suitable place to share them until I have a
patch ready for merge into enforcer-rules
Sent from my iPod
On 29 Aug 2008, at 19:08, Jason Dillon <[EMAIL PROTECTED]> wrote:
Th
Thanks!
--jason
On Aug 29, 2008, at 7:39 PM, Brian E. Fox wrote:
My vacation, but I'll try to find time this weekend to get it done.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Friday, August 29, 2008 3:56 AM
To: Maven Developers Li
Hi everyone,
Sorry if the subject of this message is a little confusing, but we're in
the process of relabeling the code in this release candidate to be part
of a new version, a departure from the 2.0.x codebase. This release
candidate contains some large modifications, even though it's meant
Then my vote is advisory as I'm not on the PMC.
Ralph
John Casey said:
> FWIW, this will be a standard ASF vote...72h. :-)
>
> John Casey wrote:
>> Okay,
>>
>> Let's put it to a vote. We have two options:
>>
>> 1. Release the current release candidate as milestone 1 of the 2.1.0
>> codeline. The
I'm okay with frowny faces... :)
Dan Fabulich wrote:
OK, OK, you're convincing me. I was just about to write up an e-mail
about how we don't have to do it as four codebases: since 2.1.0 would
just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0,
and put all future bugfixes the
yeah, the feature-completeness is why I want to stay away from betas on
this if we go that route. Betas are supposed to be feature-complete with
bugs that are [probably] still in the system...that's not what we have here.
Stephen Connolly wrote:
I think m1 is more concrete than a beta, while si
FWIW, this will be a standard ASF vote...72h. :-)
John Casey wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it kee
I think m1 is more concrete than a beta, while signalling that it's
not feature complete
Sent from my iPod
On 29 Aug 2008, at 17:32, "Raphaël Piéroni"
<[EMAIL PROTECTED]> wrote:
+0.99 for 1
+0.01 for 2
I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would
prefer 2.1.0-beta-1
OK, OK, you're convincing me. I was just about to write up an e-mail
about how we don't have to do it as four codebases: since 2.1.0 would just
be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put
all future bugfixes there. But that'll require a lot of arguing and
discussi
I don't mind 72hrs... it's just you forgot to specify how long the
vote is open for ;-)
Sent from my iPod
On 29 Aug 2008, at 17:29, John Casey <[EMAIL PROTECTED]> wrote:
We have a good codebase now, that's not going to rot if it takes a
full 72h to decide what to call it. At that point, and
+0.99 for 1
+0.01 for 2
I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would
prefer 2.1.0-beta-1
I don't have found any document stating which pre x.y.z (with x, y, z
integers) standard maven follows.
Raphaël
2008/8/29, John Casey <[EMAIL PROTECTED]>:
> Okay,
>
> Let's put it to
We have a good codebase now, that's not going to rot if it takes a full
72h to decide what to call it. At that point, and after I spin this
latest RC12 with the two nasty bugs fixed, it should be basically a
formality to vote for the actual release, and we can get this done.
It's not 6 months
+1 for #1
John Casey wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it keeps is (relatively)
focused on only thre
On Fri, Aug 29, 2008 at 9:02 AM, John Casey <[EMAIL PROTECTED]> wrote:
> Okay,
> Let's put it to a vote. We have two options:
I have a slight preference for #2 since I prefer httpd-style
versioning ("it's just a number").
However, my vote goes to whatever John wants, since he's doing most of
the
+1 to that. I think that's actually a big advantage.
-Dan
Wendy Smoak wrote:
On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED]> wrote:
I would like to point out that if we go with option 1 then the lifespan of
2.1.x will almost certainly be very short.
This might not actually
I vote that this poll is closed in 48hrs (I only want a decision soon,
I dot care which ;-) )
Sent from my iPod
On 29 Aug 2008, at 17:02, John Casey <[EMAIL PROTECTED]> wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the
+1 for #1
Dan
On Friday 29 August 2008 12:02:12 pm John Casey wrote:
> Okay,
>
> Let's put it to a vote. We have two options:
>
> 1. Release the current release candidate as milestone 1 of the 2.1.0
> codeline. The version for this release would be 2.1.0-M1.
>
> The advantage of this approach
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it keeps is (relatively) focused
on only three simultaneous codebases, not
option 1 is the "kill off 2.0, we moved it to 2.1 because there are a
lot of code changes that had to be made" option
option 2 is the "let's make 2.1 right but piss everyone off while we
release late release never"
option 1 is also the version numbers are cheap option
my experience with Hu
On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED]> wrote:
> I would like to point out that if we go with option 1 then the lifespan of
> 2.1.x will almost certainly be very short.
This might not actually be a bad thing. The archives are full of
"Maven 2.1" discussions that now belon
I would like to point out that if we go with option 1 then the lifespan
of 2.1.x will almost certainly be very short.
Stephen Connolly wrote:
can we hurry up and make a decision?
call a vote with the two options:
1. make 2.1.x be the replacement for 2.0.10... we're making no
promises that th
can we hurry up and make a decision?
call a vote with the two options:
1. make 2.1.x be the replacement for 2.0.10... we're making no
promises that there'll be a 2.0.10... the new features will now be in
2.2.x
2. spin a 2.1.0-m1 to get the 2.0.10-tc stuff "out there" and push for
2.1.0 i
I must agree with John here. It is hard for me to promote 2.1.0 to
all developers without significant feature enhancements. 2.0.9 works
great for us.
-D
On Fri, Aug 29, 2008 at 8:28 AM, Ralph Goers <[EMAIL PROTECTED]> wrote:
> As I said before, I very much agree with this.
> Ralph
>
> John C
As I said before, I very much agree with this.
Ralph
John Casey wrote:
Releasing the current RC work is exactly what I was proposing, and
what I am proposing now. The only difference was that I changed my own
perspective on this a little...if we're not introducing new features,
there is very
I don't have a very strong opinion on the name of the release we're
about to do, only that it not be blocked by anything new. Also, I'm
concerned at the thought of having too many versions up in the air
supposedly progressing toward a release...releasing the current RC as
2.1.0 GA would mean th
Releasing the current RC work is exactly what I was proposing, and what
I am proposing now. The only difference was that I changed my own
perspective on this a little...if we're not introducing new features,
there is very little to distinguish this RC code from the code in 2.0.x.
Further, if we
Stephen Connolly wrote:
does it alter cr+lf pairs?
It looks for the artifactId element. It then copies the text from before
or after that element and puts that before or after itself depending on
whether the element is being added before or after the artifactId. In
all my tests it ends up lo
does it alter cr+lf pairs?
does it change formatting of attributes within tags (eg custom
enforcer rules)?
Sent from my iPod
On 29 Aug 2008, at 15:21, Ralph Goers <[EMAIL PROTECTED]>
wrote:
Yes. The original pom.xml is used and only the artifactId, groupId,
version or parent version a
Yes. The original pom.xml is used and only the artifactId, groupId,
version or parent version are modified or added as needed.
Benjamin Bentmann wrote:
Ralph Goers wrote:
This change will have a minor impact on existing projects. If you
don't specify the artifact's groupId or versionId (i.e.
Hi Vincent,
Author: vsiveton
Date: Fri Aug 29 05:22:19 2008
New Revision: 690203
URL: http://svn.apache.org/viewvc?rev=690203&view=rev
Log:
o ordering mojodescriptors and parameters
Modified:
maven/plugin-tools/trunk/maven-plugin-tools-api/src/main/java/org/apache/maven/tools/plugin/genera
+1
Dan
On Friday 29 August 2008 5:13:41 am Mark Hobson wrote:
> 2008/8/27 Mark Hobson <[EMAIL PROTECTED]>:
> > 2008/8/26 Olivier Lamy <[EMAIL PROTECTED]>:
> >> +1 (in the future could you provide a link to the jira issues ?)
> >
> > I've now tidied up JIRA:
> >
> > We solved 1 issue:
> > http:
Sorry Jason, I didn't see this thread
Yes, we have all the same issue with SVN 1.5
A workaround (working for me) is to checkout the trunk just before doing the
release.
Arnaud
On Fri, Aug 29, 2008 at 3:01 PM, Stephen Duncan Jr <[EMAIL PROTECTED]
> wrote:
> There's been some discussion on that th
There's been some discussion on that thread, as well as this one:
http://www.nabble.com/Release-fails-during-SVN-commit-td19084270.html
-Stephen
On Thu, Aug 28, 2008 at 1:15 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Anyone?
>
> --jason
>
>
> On Thu, Aug 21, 2008 at 3:52 PM, Jason Dillon <[EM
I also prefer that we release the current branch as is.
The 2.1.0 will have only one significant change : the stability.
I think it is enough.
We'll add more new things on 2.X. I don't think that it is a good idea if we
add new features and instabilities in this branch that was long to
deliver...
My vacation, but I'll try to find time this weekend to get it done.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Friday, August 29, 2008 3:56 AM
To: Maven Developers List
Subject: When will m-enforcer-p be released so that
requirePluginVer
from my reading of the rules for sandbox plugins, I'm not allowed to
push them to a repo... hence looking to release from the sandbox
in answer to your question,
if you have aggregation separated from inheritance: yes
if aggregation is combined with inheritance: yes if the mavenvreactor
can
Hi Dan,
Thanks to take time to test it and fix issues!
I will revert the release, fix some pbs and propose a new release soon.
Cheers,
Vincent
2008/8/29 Dan Fabulich <[EMAIL PROTECTED]>:
> OK, I've added fixes I care about.
>
> -Dan
>
> Dan Fabulich wrote:
>
>> -1, though I could be convinced t
Brian E. Fox wrote:
Exactly. I don't think we need to reopen this up to a bunch more
changes, we can make more releases later. If I thought we would be
opening a can of worms for this originally, I probably wouldn't have
been in favor of it. My understanding was that 2.0.10 became 2.1.0 and
more
2008/8/29 <[EMAIL PROTECTED]>:
> Author: dfabulich
> Date: Thu Aug 28 21:53:44 2008
> New Revision: 690099
>
> URL: http://svn.apache.org/viewvc?rev=690099&view=rev
> Log:
> [MPH-49] help:describe no-arg error doesn't mention "cmd"
>
> Modified:
>
> maven/plugins/trunk/maven-help-plugin/src/ma
2008/8/27 Mark Hobson <[EMAIL PROTECTED]>:
> 2008/8/26 Olivier Lamy <[EMAIL PROTECTED]>:
>> +1 (in the future could you provide a link to the jira issues ?)
>
> I've now tidied up JIRA:
>
> We solved 1 issue:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version
Ralph Goers wrote:
This change will have a minor impact on existing projects. If you don't
specify the artifact's groupId or versionId (i.e. it is inherited from
the parent) then a new pom.xml should get created in the target
directory that has those fields filled in. That file will be the one
Its been a long time... still waiting for a release so I can use the
requirePluginVersions rule. What is holding it back from a release?
--jason
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EM
50 matches
Mail list logo
