Maven 2.1.0 GA Plan

[John Casey-5]

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 earlier comments, I've
gathered that the following may be good targets to include for 2.1.0:

- 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 is in, and on
what timeline they can be stabilized. Do the relevant developers have
enough time to finish implementing, testing, and documenting each
feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
better approach would be to try for a new milestone release that
contains the final result of each new feature (with latent parts of the
rest, as we work on them), such that the 2.1.0 GA will contain all the
new features in their complete forms, with any regressions identified
fixed and incorporated?

I haven't found the pertinent Confluence pages describing the above
features yet...maybe they don't exist or maybe I haven't looked hard
enough yet, but we'll need to collect the list somewhere that we can
make it public going forward, and then publish that release plan URL on
the Maven site.

Are there other things that we can fit into this sort of timeframe? Is
this too much? It's my strong preference that we try to cap this release
cycle at two months, so I guess this means taking the list of "nearly
there" features and determining whether we'll have the time to stabilize
them for inclusion, given our current availability.

Of course, once we settle the 2.1.0 release plan, we can start talking
about what we're going to do for 2.2, 2.3, etc. As long as we keep
things rolling, there's no reason anyone needs to feel overly rushed
about getting a particular feature in a particular release...it should
NOT be your only chance. :-)

What does anyone else think?

-john

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jason van Zyl-2]

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 Goers wrote:

> 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 out.
>
> 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 that is installed or deployed.
>
> I'm only trying to resolve the parent version. I could try to  
> resolve the parent groupId and artifactId and some of the problem  
> reports mention those but I just couldn't think of a reason why they  
> shouldn't be specified or why someone would want them in a variable.
>
> The version is obtained by
> 1. Resolving any variables provided via system properties (variables  
> from parents won't be found since the parent isn't known.
> 2. Looking in the file cache for the resolved parent project using  
> the relative location as the key.
> 3. Looking for the parent at the relative path on disk.
> a. The target directory at the relative path is inspected for a  
> modified pom.
> b. The project at the relative path is used.
> If at the end of this a resolved parent version is not located throw  
> an Exception. Do not try to recurse to further parents.
>
> You'll notice the comment about looking for the modified pom in the  
> target directory. As part of this fix the parent version, and the  
> project's artifactId, groupId and version are all interpolated. If  
> any of those fields were missing or had variables in them in the  
> original pom then the pom is modified and written to the target  
> directory. Thus, any pom that is installed or deployed will always  
> have these fields resolved.
>
> In looking through the plugins it looked to me that the Eclipse and  
> Invoker plugins are trying to locate the base directory by calling  
> project.getFile().getParentFile(). These will need to be changed to  
> project.getBasedir() since the location of the pom might now be in a  
> different place and project.getFile().getParentFile() might return  
> the target directory instead of the base directory.
>
> As we agreed Maven 2.1 will require Java 5. The pom has been changed  
> to reflect that and quite a bit of the new code uses it.
>
> Please test and provide feedback.
>
> Ralph
>
> 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 that feature list. From earlier comments, I've  
>> gathered that the following may be good targets to include for 2.1.0:
>>
>> - 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 is in,  
>> and on what timeline they can be stabilized. Do the relevant  
>> developers have enough time to finish implementing, testing, and  
>> documenting each feature, so we could get a 2.1.0 GA out in, say 6  
>> weeks or so? Maybe a better approach would be to try for a new  
>> milestone release that contains the final result of each new  
>> feature (with latent parts of the rest, as we work on them), such  
>> that the 2.1.0 GA will contain all the new features in their  
>> complete forms, with any regressions identified fixed and  
>> incorporated?
>>
>> I haven't found the pertinent Confluence pages describing the above  
>> features yet...maybe they don't exist or maybe I haven't looked  
>> hard enough yet, but we'll need to collect the list somewhere that  
>> we can make it public going forward, and then publish that release  
>> plan URL on the Maven site.
>>
>> Are there other things that we can fit into this sort of timeframe?  
>> Is this too much? It's my strong preference that we try to cap this  
>> release cycle at two months, so I guess this means taking the list  
>> of "nearly there" features and determining whether we'll have the  
>> time to stabilize them for inclusion, given our current availability.
>>
>> Of course, once we settle the 2.1.0 release plan, we can start  
>> talking about what we're going to do for 2.2, 2.3, etc. As long as  
>> we keep things rolling, there's no reason anyone needs to feel  
>> overly rushed about getting a particular feature in a particular  
>> release...it should NOT be your only chance. :-)
>>
>> What does anyone else think?
>>
>> -john
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
----------------------------------------------------------

We know what we are, but know not what we may be.

   -- Shakespeare


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

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 out.

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
that is installed or deployed.

I'm only trying to resolve the parent version. I could try to resolve
the parent groupId and artifactId and some of the problem reports
mention those but I just couldn't think of a reason why they shouldn't
be specified or why someone would want them in a variable.

The version is obtained by
1. Resolving any variables provided via system properties (variables
from parents won't be found since the parent isn't known.
2. Looking in the file cache for the resolved parent project using the
relative location as the key.
3. Looking for the parent at the relative path on disk.
a. The target directory at the relative path is inspected for a modified
pom.
b. The project at the relative path is used.
If at the end of this a resolved parent version is not located throw an
Exception. Do not try to recurse to further parents.

You'll notice the comment about looking for the modified pom in the
target directory. As part of this fix the parent version, and the
project's artifactId, groupId and version are all interpolated. If any
of those fields were missing or had variables in them in the original
pom then the pom is modified and written to the target directory. Thus,
any pom that is installed or deployed will always have these fields
resolved.

In looking through the plugins it looked to me that the Eclipse and
Invoker plugins are trying to locate the base directory by calling
project.getFile().getParentFile(). These will need to be changed to
project.getBasedir() since the location of the pom might now be in a
different place and project.getFile().getParentFile() might return the
target directory instead of the base directory.

As we agreed Maven 2.1 will require Java 5. The pom has been changed to
reflect that and quite a bit of the new code uses it.

Please test and provide feedback.

Ralph

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 that feature list. From earlier comments, I've
> gathered that the following may be good targets to include for 2.1.0:
>
> - 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 is in, and
> on what timeline they can be stabilized. Do the relevant developers
> have enough time to finish implementing, testing, and documenting each
> feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
> better approach would be to try for a new milestone release that
> contains the final result of each new feature (with latent parts of
> the rest, as we work on them), such that the 2.1.0 GA will contain all
> the new features in their complete forms, with any regressions
> identified fixed and incorporated?
>
> I haven't found the pertinent Confluence pages describing the above
> features yet...maybe they don't exist or maybe I haven't looked hard
> enough yet, but we'll need to collect the list somewhere that we can
> make it public going forward, and then publish that release plan URL
> on the Maven site.
>
> Are there other things that we can fit into this sort of timeframe? Is
> this too much? It's my strong preference that we try to cap this
> release cycle at two months, so I guess this means taking the list of
> "nearly there" features and determining whether we'll have the time to
> stabilize them for inclusion, given our current availability.
>
> Of course, once we settle the 2.1.0 release plan, we can start talking
> about what we're going to do for 2.2, 2.3, etc. As long as we keep
> things rolling, there's no reason anyone needs to feel overly rushed
> about getting a particular feature in a particular release...it should
> NOT be your only chance. :-)
>
> What does anyone else think?
>
> -john
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

We've come this far, 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:jdcasey@...]
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 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 earlier comments, I've
gathered that the following may be good targets to include for 2.1.0:

- 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 is in, and on
what timeline they can be stabilized. Do the relevant developers have
enough time to finish implementing, testing, and documenting each
feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
better approach would be to try for a new milestone release that
contains the final result of each new feature (with latent parts of the
rest, as we work on them), such that the 2.1.0 GA will contain all the
new features in their complete forms, with any regressions identified
fixed and incorporated?

I haven't found the pertinent Confluence pages describing the above
features yet...maybe they don't exist or maybe I haven't looked hard
enough yet, but we'll need to collect the list somewhere that we can
make it public going forward, and then publish that release plan URL on
the Maven site.

Are there other things that we can fit into this sort of timeframe? Is
this too much? It's my strong preference that we try to cap this release

cycle at two months, so I guess this means taking the list of "nearly
there" features and determining whether we'll have the time to stabilize

them for inclusion, given our current availability.

Of course, once we settle the 2.1.0 release plan, we can start talking
about what we're going to do for 2.2, 2.3, etc. As long as we keep
things rolling, there's no reason anyone needs to feel overly rushed
about getting a particular feature in a particular release...it should
NOT be your only chance. :-)

What does anyone else think?

-john

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

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 see what you intend.
> It's hard to grok entirely from your description.
>
> On 28-Aug-08, at 4:11 PM, Ralph Goers wrote:
>
>> 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 out.
>>
>> 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 that is installed or deployed.
>>
>> I'm only trying to resolve the parent version. I could try to resolve
>> the parent groupId and artifactId and some of the problem reports
>> mention those but I just couldn't think of a reason why they
>> shouldn't be specified or why someone would want them in a variable.
>>
>> The version is obtained by
>> 1. Resolving any variables provided via system properties (variables
>> from parents won't be found since the parent isn't known.
>> 2. Looking in the file cache for the resolved parent project using
>> the relative location as the key.
>> 3. Looking for the parent at the relative path on disk.
>> a. The target directory at the relative path is inspected for a
>> modified pom.
>> b. The project at the relative path is used.
>> If at the end of this a resolved parent version is not located throw
>> an Exception. Do not try to recurse to further parents.
>>
>> You'll notice the comment about looking for the modified pom in the
>> target directory. As part of this fix the parent version, and the
>> project's artifactId, groupId and version are all interpolated. If
>> any of those fields were missing or had variables in them in the
>> original pom then the pom is modified and written to the target
>> directory. Thus, any pom that is installed or deployed will always
>> have these fields resolved.
>>
>> In looking through the plugins it looked to me that the Eclipse and
>> Invoker plugins are trying to locate the base directory by calling
>> project.getFile().getParentFile(). These will need to be changed to
>> project.getBasedir() since the location of the pom might now be in a
>> different place and project.getFile().getParentFile() might return
>> the target directory instead of the base directory.
>>
>> As we agreed Maven 2.1 will require Java 5. The pom has been changed
>> to reflect that and quite a bit of the new code uses it.
>>
>> Please test and provide feedback.
>>
>> Ralph
>>
>> 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 that feature list. From earlier comments, I've
>>> gathered that the following may be good targets to include for 2.1.0:
>>>
>>> - 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 is in, and
>>> on what timeline they can be stabilized. Do the relevant developers
>>> have enough time to finish implementing, testing, and documenting
>>> each feature, so we could get a 2.1.0 GA out in, say 6 weeks or so?
>>> Maybe a better approach would be to try for a new milestone release
>>> that contains the final result of each new feature (with latent
>>> parts of the rest, as we work on them), such that the 2.1.0 GA will
>>> contain all the new features in their complete forms, with any
>>> regressions identified fixed and incorporated?
>>>
>>> I haven't found the pertinent Confluence pages describing the above
>>> features yet...maybe they don't exist or maybe I haven't looked hard
>>> enough yet, but we'll need to collect the list somewhere that we can
>>> make it public going forward, and then publish that release plan URL
>>> on the Maven site.
>>>
>>> Are there other things that we can fit into this sort of timeframe?
>>> Is this too much? It's my strong preference that we try to cap this
>>> release cycle at two months, so I guess this means taking the list
>>> of "nearly there" features and determining whether we'll have the
>>> time to stabilize them for inclusion, given our current availability.
>>>
>>> Of course, once we settle the 2.1.0 release plan, we can start
>>> talking about what we're going to do for 2.2, 2.3, etc. As long as
>>> we keep things rolling, there's no reason anyone needs to feel
>>> overly rushed about getting a particular feature in a particular
>>> release...it should NOT be your only chance. :-)
>>>
>>> What does anyone else think?
>>>
>>> -john
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> ----------------------------------------------------------
>
> We know what we are, but know not what we may be.
>
>   -- Shakespeare
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

The question is at what point do you say "no new stuff" on 2.1?  IMO,
there needs to be a fair amount of time for "unstable" things to be
introduced in 2.1 before a formal release is made.  In other words, I'd
like to see a process where we have a branch that is stable and a branch
in "development mode". When the development mode branch is marked stable
a new development branch should be created. At the same time the old
stable branch should be retired.  Thus the length of time a branch is in
development mode should be long enough that the stable branches have a
reasonable life span.

In short, I like the milestone approach as it is a clear signal to users
that things are somewhat subject to change.

Ralph

Brian E. Fox wrote:

> We've come this far, 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:jdcasey@...]
> 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 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 earlier comments, I've
> gathered that the following may be good targets to include for 2.1.0:
>
> - 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 is in, and on
> what timeline they can be stabilized. Do the relevant developers have
> enough time to finish implementing, testing, and documenting each
> feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
> better approach would be to try for a new milestone release that
> contains the final result of each new feature (with latent parts of the
> rest, as we work on them), such that the 2.1.0 GA will contain all the
> new features in their complete forms, with any regressions identified
> fixed and incorporated?
>
> I haven't found the pertinent Confluence pages describing the above
> features yet...maybe they don't exist or maybe I haven't looked hard
> enough yet, but we'll need to collect the list somewhere that we can
> make it public going forward, and then publish that release plan URL on
> the Maven site.
>
> Are there other things that we can fit into this sort of timeframe? Is
> this too much? It's my strong preference that we try to cap this release
>
> cycle at two months, so I guess this means taking the list of "nearly
> there" features and determining whether we'll have the time to stabilize
>
> them for inclusion, given our current availability.
>
> Of course, once we settle the 2.1.0 release plan, we can start talking
> about what we're going to do for 2.2, 2.3, etc. As long as we keep
> things rolling, there's no reason anyone needs to feel overly rushed
> about getting a particular feature in a particular release...it should
> NOT be your only chance. :-)
>
> What does anyone else think?
>
> -john
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[dfabulich]

+0.5 We should release that code that we did all that RC testing on, right
away, and I don't care what we call it; I thought that was what John was
proposing in his earlier [PROPOSAL].

-Dan

Brian E. Fox wrote:

> We've come this far, 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:jdcasey@...]
> 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 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 earlier comments, I've
> gathered that the following may be good targets to include for 2.1.0:
>
> - 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 is in, and on
> what timeline they can be stabilized. Do the relevant developers have
> enough time to finish implementing, testing, and documenting each
> feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
> better approach would be to try for a new milestone release that
> contains the final result of each new feature (with latent parts of the
> rest, as we work on them), such that the 2.1.0 GA will contain all the
> new features in their complete forms, with any regressions identified
> fixed and incorporated?
>
> I haven't found the pertinent Confluence pages describing the above
> features yet...maybe they don't exist or maybe I haven't looked hard
> enough yet, but we'll need to collect the list somewhere that we can
> make it public going forward, and then publish that release plan URL on
> the Maven site.
>
> Are there other things that we can fit into this sort of timeframe? Is
> this too much? It's my strong preference that we try to cap this release
>
> cycle at two months, so I guess this means taking the list of "nearly
> there" features and determining whether we'll have the time to stabilize
>
> them for inclusion, given our current availability.
>
> Of course, once we settle the 2.1.0 release plan, we can start talking
> about what we're going to do for 2.2, 2.3, etc. As long as we keep
> things rolling, there's no reason anyone needs to feel overly rushed
> about getting a particular feature in a particular release...it should
> NOT be your only chance. :-)
>
> What does anyone else think?
>
> -john
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian E Fox]

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 changes would follow on 2.x since we moved out 3.0.

-----Original Message-----
From: Dan Fabulich [mailto:dan@...]
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, and I don't care what we call it; I thought that was what John was

proposing in his earlier [PROPOSAL].

-Dan

Brian E. Fox wrote:

> We've come this far, 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:jdcasey@...]
> 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 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 earlier comments, I've
> gathered that the following may be good targets to include for 2.1.0:
>
> - 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 is in, and

on
> what timeline they can be stabilized. Do the relevant developers have
> enough time to finish implementing, testing, and documenting each
> feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
> better approach would be to try for a new milestone release that
> contains the final result of each new feature (with latent parts of
the
> rest, as we work on them), such that the 2.1.0 GA will contain all the
> new features in their complete forms, with any regressions identified
> fixed and incorporated?
>
> I haven't found the pertinent Confluence pages describing the above
> features yet...maybe they don't exist or maybe I haven't looked hard
> enough yet, but we'll need to collect the list somewhere that we can
> make it public going forward, and then publish that release plan URL
on
> the Maven site.
>
> Are there other things that we can fit into this sort of timeframe? Is
> this too much? It's my strong preference that we try to cap this
release
>
> cycle at two months, so I guess this means taking the list of "nearly
> there" features and determining whether we'll have the time to
stabilize

>
> them for inclusion, given our current availability.
>
> Of course, once we settle the 2.1.0 release plan, we can start talking
> about what we're going to do for 2.2, 2.3, etc. As long as we keep
> things rolling, there's no reason anyone needs to feel overly rushed
> about getting a particular feature in a particular release...it should
> NOT be your only chance. :-)
>
> What does anyone else think?
>
> -john
>
> --
> John Casey
> Developer, PMC Member - Apache Maven (http://maven.apache.org)
> Blog: http://www.ejlife.net/blogs/buildchimp/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

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
> that is installed or deployed.

And it is guaranteed that the transformed POM doesn't loose XML
declaration, license header and things like?


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Mauro Talevi]

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 changes would follow on 2.x since we moved out 3.0.
>

I agree with Brian.  However tempting to have more features creep in
because of the new dot release (as opposed to dot dot) it's better to
release a stable version (on which there is now a consensus that it has
sufficiently evolved from 2.0.x branch) and focus on next release.

Release early, release often ... etc :-)

Cheers


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Arnaud HERITIER]

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...

Arnaud



On Fri, Aug 29, 2008 at 11:45 AM, Mauro Talevi
<mauro.talevi@...>wrote:

> 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 changes would follow on 2.x since we moved out 3.0.
>>
>>
> I agree with Brian.  However tempting to have more features creep in
> because of the new dot release (as opposed to dot dot) it's better to
> release a stable version (on which there is now a consensus that it has
> sufficiently evolved from 2.0.x branch) and focus on next release.
>
> Release early, release often ... etc :-)
>
> Cheers
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
..........................................................
Arnaud HERITIER
..........................................................
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..........................................................
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...........................................................

[Ralph Goers]

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. 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 that is installed or deployed.
>
> And it is guaranteed that the transformed POM doesn't loose XML
> declaration, license header and things like?
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stephen Connolly-2]

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 <Ralph.Goers@...>  
wrote:

> 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. 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 that is installed or deployed.
>>
>> And it is guaranteed that the transformed POM doesn't loose XML  
>> declaration, license header and things like?
>>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

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 looking like you had coded it yourself as it
lines up nicely.
>
> does it change formatting of attributes within tags (eg custom
> enforcer rules)?
In my tests the formatting of everything else stayed the same.

Please test it for yourself and see if it does what you want.

Ralph

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

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 plan to introduce new features next, then we're really
talking about having 2.0.x and 2.1.0 be basically the same, no new
features for 2.1.1 since that's bad juju, and then, in 2.2, we finally
get some new features.

I guess I see that as a little awkward. Agreed, the work we've done
leading up to this RC process (and into it) has changed quite a bit of
code, but part of why this RC process has been so long is that we're
taking great care to make sure it's fully backward compatible. If we
were bringing huge gains in terms of fixing horrible bugs with this
code, I'd say that 2.1.0 is great, and any regressions found there could
go in 2.1.1, etc. But the worst things we're really fixing in this
release is performance (it's better than 2.0.9, not that 2.0.9 was that
horrible) and regressions caused by the release of 2.0.9.

I'm gambling that the version 2.1.0-M1 won't be too big of a
psychological hit to keep people from using it; maybe that's off target.
In any case, I was hoping that by declaring this a M1 and immediately
setting up a 2.1.0 release plan (hopefully before calling the vote for
M1), that we could keep things on track, get new features for 2.1.0, and
avoid having 2.0.10, 2.1.1, 2.2.0, and 3.0 all in the works at the same
time. From my experience of the activity levels in this project, that
would be overreaching. Hell, we have plugins that need work and that are
pretty badly neglected right now.

WDYT?

-john

Dan Fabulich wrote:

>
> +0.5 We should release that code that we did all that RC testing on,
> right away, and I don't care what we call it; I thought that was what
> John was proposing in his earlier [PROPOSAL].
>
> -Dan
>
> Brian E. Fox wrote:
>
>> We've come this far, 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:jdcasey@...]
>> 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 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 earlier comments, I've
>> gathered that the following may be good targets to include for 2.1.0:
>>
>> - 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 is in, and on
>> what timeline they can be stabilized. Do the relevant developers have
>> enough time to finish implementing, testing, and documenting each
>> feature, so we could get a 2.1.0 GA out in, say 6 weeks or so? Maybe a
>> better approach would be to try for a new milestone release that
>> contains the final result of each new feature (with latent parts of the
>> rest, as we work on them), such that the 2.1.0 GA will contain all the
>> new features in their complete forms, with any regressions identified
>> fixed and incorporated?
>>
>> I haven't found the pertinent Confluence pages describing the above
>> features yet...maybe they don't exist or maybe I haven't looked hard
>> enough yet, but we'll need to collect the list somewhere that we can
>> make it public going forward, and then publish that release plan URL on
>> the Maven site.
>>
>> Are there other things that we can fit into this sort of timeframe? Is
>> this too much? It's my strong preference that we try to cap this release
>>
>> cycle at two months, so I guess this means taking the list of "nearly
>> there" features and determining whether we'll have the time to stabilize
>>
>> them for inclusion, given our current availability.
>>
>> Of course, once we settle the 2.1.0 release plan, we can start talking
>> about what we're going to do for 2.2, 2.3, etc. As long as we keep
>> things rolling, there's no reason anyone needs to feel overly rushed
>> about getting a particular feature in a particular release...it should
>> NOT be your only chance. :-)
>>
>> What does anyone else think?
>>
>> -john
>>
>> --
>> John Casey
>> Developer, PMC Member - Apache Maven (http://maven.apache.org)
>> Blog: http://www.ejlife.net/blogs/buildchimp/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[John Casey-5]

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 that we have up to four codelines headed toward a
release all at once: 2.0.10 (still planning to do this), 2.1.1 (for
regressions), 2.2.0 (for first wave of new features), and 3.0.

Can we really handle the bedlam that four simultaneous active dev
branches will bring?

Arnaud HERITIER wrote:

> 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...
>
> Arnaud
>
>
>
> On Fri, Aug 29, 2008 at 11:45 AM, Mauro Talevi
> <mauro.talevi@...>wrote:
>
>> 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 changes would follow on 2.x since we moved out 3.0.
>>>
>>>
>> I agree with Brian.  However tempting to have more features creep in
>> because of the new dot release (as opposed to dot dot) it's better to
>> release a stable version (on which there is now a consensus that it has
>> sufficiently evolved from 2.0.x branch) and focus on next release.
>>
>> Release early, release often ... etc :-)
>>
>> Cheers
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>

--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

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 little to distinguish this RC code from the code in
> 2.0.x. Further, if we plan to introduce new features next, then we're
> really talking about having 2.0.x and 2.1.0 be basically the same, no
> new features for 2.1.1 since that's bad juju, and then, in 2.2, we
> finally get some new features.
>
> I guess I see that as a little awkward. Agreed, the work we've done
> leading up to this RC process (and into it) has changed quite a bit of
> code, but part of why this RC process has been so long is that we're
> taking great care to make sure it's fully backward compatible. If we
> were bringing huge gains in terms of fixing horrible bugs with this
> code, I'd say that 2.1.0 is great, and any regressions found there
> could go in 2.1.1, etc. But the worst things we're really fixing in
> this release is performance (it's better than 2.0.9, not that 2.0.9
> was that horrible) and regressions caused by the release of 2.0.9.
>
> I'm gambling that the version 2.1.0-M1 won't be too big of a
> psychological hit to keep people from using it; maybe that's off
> target. In any case, I was hoping that by declaring this a M1 and
> immediately setting up a 2.1.0 release plan (hopefully before calling
> the vote for M1), that we could keep things on track, get new features
> for 2.1.0, and avoid having 2.0.10, 2.1.1, 2.2.0, and 3.0 all in the
> works at the same time. From my experience of the activity levels in
> this project, that would be overreaching. Hell, we have plugins that
> need work and that are pretty badly neglected right now.
>
> WDYT?
>
> -john
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dan Tran]

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 <Ralph.Goers@...> wrote:

> 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
>> little to distinguish this RC code from the code in 2.0.x. Further, if we
>> plan to introduce new features next, then we're really talking about having
>> 2.0.x and 2.1.0 be basically the same, no new features for 2.1.1 since
>> that's bad juju, and then, in 2.2, we finally get some new features.
>>
>> I guess I see that as a little awkward. Agreed, the work we've done
>> leading up to this RC process (and into it) has changed quite a bit of code,
>> but part of why this RC process has been so long is that we're taking great
>> care to make sure it's fully backward compatible. If we were bringing huge
>> gains in terms of fixing horrible bugs with this code, I'd say that 2.1.0 is
>> great, and any regressions found there could go in 2.1.1, etc. But the worst
>> things we're really fixing in this release is performance (it's better than
>> 2.0.9, not that 2.0.9 was that horrible) and regressions caused by the
>> release of 2.0.9.
>>
>> I'm gambling that the version 2.1.0-M1 won't be too big of a psychological
>> hit to keep people from using it; maybe that's off target. In any case, I
>> was hoping that by declaring this a M1 and immediately setting up a 2.1.0
>> release plan (hopefully before calling the vote for M1), that we could keep
>> things on track, get new features for 2.1.0, and avoid having 2.0.10, 2.1.1,
>> 2.2.0, and 3.0 all in the works at the same time. From my experience of the
>> activity levels in this project, that would be overreaching. Hell, we have
>> plugins that need work and that are pretty badly neglected right now.
>>
>> WDYT?
>>
>> -john
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stephen Connolly-2]

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 in the next 4 weeks... any features not in 2.1 by then will have  
to wait for 2.2... after 4 weeks we start stabilizing until we have a  
2.1.0 released

Sent from my iPod

On 29 Aug 2008, at 16:32, "Dan Tran" <dantran@...> wrote:

> 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 <Ralph.Goers@...
> > wrote:
>> 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
>>> little to distinguish this RC code from the code in 2.0.x.  
>>> Further, if we
>>> plan to introduce new features next, then we're really talking  
>>> about having
>>> 2.0.x and 2.1.0 be basically the same, no new features for 2.1.1  
>>> since
>>> that's bad juju, and then, in 2.2, we finally get some new features.
>>>
>>> I guess I see that as a little awkward. Agreed, the work we've done
>>> leading up to this RC process (and into it) has changed quite a  
>>> bit of code,
>>> but part of why this RC process has been so long is that we're  
>>> taking great
>>> care to make sure it's fully backward compatible. If we were  
>>> bringing huge
>>> gains in terms of fixing horrible bugs with this code, I'd say  
>>> that 2.1.0 is
>>> great, and any regressions found there could go in 2.1.1, etc. But  
>>> the worst
>>> things we're really fixing in this release is performance (it's  
>>> better than
>>> 2.0.9, not that 2.0.9 was that horrible) and regressions caused by  
>>> the
>>> release of 2.0.9.
>>>
>>> I'm gambling that the version 2.1.0-M1 won't be too big of a  
>>> psychological
>>> hit to keep people from using it; maybe that's off target. In any  
>>> case, I
>>> was hoping that by declaring this a M1 and immediately setting up  
>>> a 2.1.0
>>> release plan (hopefully before calling the vote for M1), that we  
>>> could keep
>>> things on track, get new features for 2.1.0, and avoid having  
>>> 2.0.10, 2.1.1,
>>> 2.2.0, and 3.0 all in the works at the same time. From my  
>>> experience of the
>>> activity levels in this project, that would be overreaching. Hell,  
>>> we have
>>> plugins that need work and that are pretty badly neglected right  
>>> now.
>>>
>>> WDYT?
>>>
>>> -john
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Ralph Goers]

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 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 in the next 4 weeks... any features not in 2.1 by then will have
> to wait for 2.2... after 4 weeks we start stabilizing until we have a
> 2.1.0 released
>
> Sent from my iPod
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...