>>>> in some way to the refactoring happening in 3.0... but I know that 2.0.x
>>>> can't handle newer models and the sooner we start moving to a more
>>>> flexible parser, the easier the eventual migration to 3.0 will be.
>>>> I'm not sure this
Please see
http://docs.codehaus.org/display/MAVEN/Automatic+Parent+Versioning. I've
also linked it from the Release Plan document.
Ralph
John Casey wrote:
I've read MNG-624, and quite a bit of the code, and I feel like I
understand the algorithm relatively well. What I'm having trouble
under
On 04/09/2008, at 1:34 AM, John Casey wrote:
So, I've started tracking the features I proposed for 2.1.0 GA here:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
I don't know if this is the final list; IMO we'll need to agree on
that once we have design documentation for eve
Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday,
September 03, 2008 2:31 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 GA Plan
I've included this as M2 to give us a clean base in M1:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
Let
ist for 2.2.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] Sent: Wednesday,
September 03, 2008 2:31 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 GA Plan
I've included this as M2 to give us a clean base in M1:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Re
PROTECTED] Sent: Wednesday,
September 03, 2008 2:31 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 GA Plan
I've included this as M2 to give us a clean base in M1:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
Let me know what you think.
Dennis Lundberg wrote:
John Cas
er the eventual migration to 3.0 will be.
I'm not sure this needs to be in 2.1, but maybe on the list for 2.2.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 2:31 PM
To: Maven Developers List
Subject: Re: Maven 2.1.0 GA Plan
I'
xible parser, the easier the eventual migration to 3.0 will be.
I'm not sure this needs to be in 2.1, but maybe on the list for 2.2.
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 03, 2008 2:31 PM
To: Maven Developers List
Subject: Re: Maven 2.1
That sounds fine to me.
John Casey wrote:
> I've included this as M2 to give us a clean base in M1:
>
> http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
>
> Let me know what you think.
>
>
>
> Dennis Lundberg wrote:
>> John Casey wrote:
>>> Hi everyone,
>>>
>>> So, it seems tha
I've included this as M2 to give us a clean base in M1:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
Let me know what you think.
Dennis Lundberg wrote:
John Casey wrote:
Hi everyone,
So, it seems that we're all in agreement about the rough outline for
2.1.x and beyond. I
John Casey wrote:
> Hi everyone,
>
> So, it seems that we're all in agreement about the rough outline for
> 2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC
> to make this the first milestone toward some as-yet-undetermined feature
> list for 2.1.0.
>
> So, let's talk about
So, I've started tracking the features I proposed for 2.1.0 GA here:
http://docs.codehaus.org/display/MAVEN/Maven+2.1.0+Release+Plan
I don't know if this is the final list; IMO we'll need to agree on that
once we have design documentation for everything. I'm going to contact
Don Brown today an
I've read MNG-624, and quite a bit of the code, and I feel like I
understand the algorithm relatively well. What I'm having trouble
understanding is why it needs to be so complex and look for versions in
so many places (like resolving system properties in the parent section,
etc.). IMO we need
John, that's not a problem. I'll be happy to put something up on the
wiki in the next day or two. The code was actually much simpler in the
beginning, but as usual when I started testing things got a little more
complicated. For reference, if you haven't read MNG-624 and its many
cousins you
Hi Ralph,
As with all of the feature branch work we've done recently (in the last
year or two), it would be extremely helpful if we could get a write-up
in the form of a proposal out on the wiki. Most importantly, to try and
address the specific use cases this design is intended to address, an
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 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
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
why not make 2.1.0 right now as we were doing
2.0.10? I don't see any benefit to waiting longer. Just do it and then
we can start adding more things to 2.1.1 or 2.2
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 6:29 PM
To: Maven Develope
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...
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
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
uld follow on 2.x since we moved out 3.0.
-Original Message-
From: Dan Fabulich [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 9:00 PM
To: Maven Developers List
Subject: RE: Maven 2.1.0 GA Plan
+0.5 We should release that code that we did all that RC testing on,
right
away, a
2.0.10? I don't see any benefit to waiting longer. Just do it and then
we can start adding more things to 2.1.1 or 2.2
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 6:29 PM
To: Maven Developers List
Subject: Maven 2.1.0 GA Plan
Hi everyone
to waiting longer. Just do it and then
we can start adding more things to 2.1.1 or 2.2
-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 28, 2008 6:29 PM
To: Maven Developers List
Subject: Maven 2.1.0 GA Plan
Hi everyone,
So, it seems that we're all i
Sure. I updated the issue. I'll try to get some sample tests checked in
as soon as I can.
Jason van Zyl wrote:
I left some initial questions and comments in JIRA. I don't care where
you answer them but I would like a little more background before
delving into code. Primarily sample projects to
08 6:29 PM
To: Maven Developers List
Subject: Maven 2.1.0 GA Plan
Hi everyone,
So, it seems that we're all in agreement about the rough outline for
2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC
to make this the first milestone toward some as-yet-undetermined fea
I left some initial questions and comments in JIRA. I don't care where
you answer them but I would like a little more background before
delving into code. Primarily sample projects to see what you intend.
It's hard to grok entirely from your description.
On 28-Aug-08, at 4:11 PM, Ralph Goer
I am OK with this.
You may or may not have noticed but I created branch maven-2.1.x-MNG-624
last night. It contains the fix for MNG-624. I have created integration
tests but haven't committed them yet. I will soon. Before committing
these to the 2.1.x branch I'd really like folks to try it
Hi everyone,
So, it seems that we're all in agreement about the rough outline for
2.1.x and beyond. I've renamed the current RC branch to be 2.1.0-M1-RC
to make this the first milestone toward some as-yet-undetermined feature
list for 2.1.0.
So, let's talk about that feature list. From earli
37 matches
Mail list logo
