Maven 2.1.0 GA Plan

[Wendy Smoak-3]

On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <Ralph.Goers@...> 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 belong to 3.0.  If we moved on to 2.2
quickly, that would be less confusing.

--
Wendy

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

[Stephen Connolly-2]

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 Hudson is that lots of releases are a good thing...  
however the problem with Hudson is deciding exactly how far to upgrade  
up to!

Sent from my iPod

On 29 Aug 2008, at 16:54, Ralph Goers <Ralph.Goers@...>  
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.
>
> 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@...
>

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

[dfabulich]

+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 <Ralph.Goers@...> 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 belong to 3.0.  If we moved on to 2.2
> quickly, that would be less confusing.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> 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@...

[brettporter]

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 <Ralph.Goers@...
> > 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 belong to 3.0.  If we moved on to 2.2
> quickly, that would be less confusing.
>
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[brettporter]

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

Yes. The PGP stuff was done some time back. I'll make it so it's not  
on by default and we can tackle those larger challenges (many affect  
the central repository more than anything) in the future.

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

"Make like reactor" and "repository security" - the others don't have  
them to my knowledge. Agreed we need to do all the release notes/user  
docs/etc.

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

Yep - I'd hope 2 months is an outside limit. The only things I'd  
consider adding are starting to deprecated behaviour we know will be  
removed to give folks a better migration path.

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

+1

- Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[John Casey-5]

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, and
how. Also, within what assumptions the code is designed to work, so we
might talk about how it could/should fall apart when the user violates
one of those assumptions.

I'm looking through the code right now, but from my own experience with
Maven, it's simply not enough going forward to keep throwing test cases
at the code and hope we haven't missed anything. I'd like to have a
basis for writing up the new feature on the public website, to explain
it to users...this will help me understand it better, too.

I know we're somewhat in the early stages of development for this stuff
- assuming we're going to enter a stabilizing mode in the next few weeks
for what should become a GA release if everything follows its current
trajectory - but personally I'm not comfortable marking this feature for
inclusion in that release until I know more about it. I'm in the middle
of reading the code, but IMO we really need some design documentation
laying out clearly the need for the feature, and the reasoning behind
the apparent complexity of your implementation, etc.

IMO we need to have these sorts of discussions before we decide to
include any new feature in a release. I'm working on reviewing the full
list I've suggested in the original email on this thread, so I'm sure
this won't be the last request like this to the list...

Thanks,

-john

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

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

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 should take a look at them.

Ralph

John Casey wrote:

> 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, and how. Also, within what assumptions the code is designed
> to work, so we might talk about how it could/should fall apart when
> the user violates one of those assumptions.
>
> I'm looking through the code right now, but from my own experience
> with Maven, it's simply not enough going forward to keep throwing test
> cases at the code and hope we haven't missed anything. I'd like to
> have a basis for writing up the new feature on the public website, to
> explain it to users...this will help me understand it better, too.
>
> I know we're somewhat in the early stages of development for this
> stuff - assuming we're going to enter a stabilizing mode in the next
> few weeks for what should become a GA release if everything follows
> its current trajectory - but personally I'm not comfortable marking
> this feature for inclusion in that release until I know more about it.
> I'm in the middle of reading the code, but IMO we really need some
> design documentation laying out clearly the need for the feature, and
> the reasoning behind the apparent complexity of your implementation, etc.
>
> IMO we need to have these sorts of discussions before we decide to
> include any new feature in a release. I'm working on reviewing the
> full list I've suggested in the original email on this thread, so I'm
> sure this won't be the last request like this to the list...
>
> Thanks,
>
> -john
>
> 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@...
>>
>

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

[John Casey-5]

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 to be very careful with things like cli arguments
here, since it could have a huge impact on build reproducibility.

Ralph Goers wrote:

> 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 should take a look at them.
>
> Ralph
>
> John Casey wrote:
>> 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, and how. Also, within what assumptions the code is designed
>> to work, so we might talk about how it could/should fall apart when
>> the user violates one of those assumptions.
>>
>> I'm looking through the code right now, but from my own experience
>> with Maven, it's simply not enough going forward to keep throwing test
>> cases at the code and hope we haven't missed anything. I'd like to
>> have a basis for writing up the new feature on the public website, to
>> explain it to users...this will help me understand it better, too.
>>
>> I know we're somewhat in the early stages of development for this
>> stuff - assuming we're going to enter a stabilizing mode in the next
>> few weeks for what should become a GA release if everything follows
>> its current trajectory - but personally I'm not comfortable marking
>> this feature for inclusion in that release until I know more about it.
>> I'm in the middle of reading the code, but IMO we really need some
>> design documentation laying out clearly the need for the feature, and
>> the reasoning behind the apparent complexity of your implementation, etc.
>>
>> IMO we need to have these sorts of discussions before we decide to
>> include any new feature in a release. I'm working on reviewing the
>> full list I've suggested in the original email on this thread, so I'm
>> sure this won't be the last request like this to the list...
>>
>> Thanks,
>>
>> -john
>>
>> 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@...
>>>
>>
>
> ---------------------------------------------------------------------
> 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]

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 and ask whether he can do a little write-up for parallel
resolution soonish, and I need to track down the build dynamism write-up
I put on Confluence (not to mention the relevant JIRAs for these
implementation changes). Ralph, once you have some design docs for the
automatic parent versioning, we'll add that in as well.

Please have a look, and give feedback! Thanks.

-john

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
>

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

[Dennis Lundberg-2]

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.

With a timeframe of 2 months I would like to see Doxia beta-1 included
in the core. This is tracked in JIRA as
http://jira.codehaus.org/browse/MNG-3602

In the discussions surrounding that issue it was determined there would
not be enough exposure of Doxia beta-1 until the next release (at that
time). But with the new timeframe for the 2.1 release we should be able
to get good testing of Doxia beta-1.

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

--
Dennis Lundberg

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

[John Casey-5]

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'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.
>
> With a timeframe of 2 months I would like to see Doxia beta-1 included
> in the core. This is tracked in JIRA as
> http://jira.codehaus.org/browse/MNG-3602
>
> In the discussions surrounding that issue it was determined there would
> not be enough exposure of Doxia beta-1 until the next release (at that
> time). But with the new timeframe for the 2.1 release we should be able
> to get good testing of Doxia beta-1.
>
>> 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@...

[Dennis Lundberg-2]

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 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.
>>
>> With a timeframe of 2 months I would like to see Doxia beta-1 included
>> in the core. This is tracked in JIRA as
>> http://jira.codehaus.org/browse/MNG-3602
>>
>> In the discussions surrounding that issue it was determined there would
>> not be enough exposure of Doxia beta-1 until the next release (at that
>> time). But with the new timeframe for the 2.1 release we should be able
>> to get good testing of Doxia beta-1.
>>
>>> 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
>>>
>>
>>
>

--
Dennis Lundberg

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

[Brian E Fox]

The only thing I feel we need to start looking at soon is an xml parser
that can deal with newer models and not freak. This is probably related
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 needs to be in 2.1, but maybe on the list for 2.2.

-----Original Message-----
From: John Casey [mailto:jdcasey@...]
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 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.
>
> With a timeframe of 2 months I would like to see Doxia beta-1 included
> in the core. This is tracked in JIRA as
> http://jira.codehaus.org/browse/MNG-3602
>
> In the discussions surrounding that issue it was determined there
would
> not be enough exposure of Doxia beta-1 until the next release (at that
> time). But with the new timeframe for the 2.1 release we should be
able
> to get good testing of Doxia beta-1.
>
>> 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@...

[John Casey-5]

Let's start another page for 2.2 features, since this one is in the
pre-planning stages still. Until we have a concrete strategy for
implementation including a design doc, I don't feel comfortable putting
it on such a near time horizon.

WDYT?

Brian E. Fox wrote:

> The only thing I feel we need to start looking at soon is an xml parser
> that can deal with newer models and not freak. This is probably related
> 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 needs to be in 2.1, but maybe on the list for 2.2.
>
> -----Original Message-----
> From: John Casey [mailto:jdcasey@...]
> 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 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.
>> With a timeframe of 2 months I would like to see Doxia beta-1 included
>> in the core. This is tracked in JIRA as
>> http://jira.codehaus.org/browse/MNG-3602
>>
>> In the discussions surrounding that issue it was determined there
> would
>> not be enough exposure of Doxia beta-1 until the next release (at that
>> time). But with the new timeframe for the 2.1 release we should be
> able
>> to get good testing of Doxia beta-1.
>>
>>> 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@...

[Brian E Fox]

Sounds good to me

Sent from my iPhone

On Sep 3, 2008, at 5:35 PM, John Casey <jdcasey@...> wrote:

> Let's start another page for 2.2 features, since this one is in the  
> pre-planning stages still. Until we have a concrete strategy for  
> implementation including a design doc, I don't feel comfortable  
> putting it on such a near time horizon.
>
> WDYT?
>
> Brian E. Fox wrote:
>> The only thing I feel we need to start looking at soon is an xml  
>> parser
>> that can deal with newer models and not freak. This is probably  
>> related
>> 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 needs to be in 2.1, but maybe on the list for 2.2.
>> -----Original Message-----
>> From: John Casey [mailto:jdcasey@...] 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 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.
>>> With a timeframe of 2 months I would like to see Doxia beta-1  
>>> included
>>> in the core. This is tracked in JIRA as
>>> http://jira.codehaus.org/browse/MNG-3602
>>>
>>> In the discussions surrounding that issue it was determined there
>> would
>>> not be enough exposure of Doxia beta-1 until the next release (at  
>>> that
>>> time). But with the new timeframe for the 2.1 release we should be
>> able
>>> to get good testing of Doxia beta-1.
>>>
>>>> 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@...

[John Casey-5]

http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan

Brian Fox wrote:

> Sounds good to me
>
> Sent from my iPhone
>
> On Sep 3, 2008, at 5:35 PM, John Casey <jdcasey@...> wrote:
>
>> Let's start another page for 2.2 features, since this one is in the
>> pre-planning stages still. Until we have a concrete strategy for
>> implementation including a design doc, I don't feel comfortable
>> putting it on such a near time horizon.
>>
>> WDYT?
>>
>> Brian E. Fox wrote:
>>> The only thing I feel we need to start looking at soon is an xml parser
>>> that can deal with newer models and not freak. This is probably related
>>> 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 needs to be in 2.1, but maybe on the list for 2.2.
>>> -----Original Message-----
>>> From: John Casey [mailto:jdcasey@...] 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 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.
>>>> With a timeframe of 2 months I would like to see Doxia beta-1 included
>>>> in the core. This is tracked in JIRA as
>>>> http://jira.codehaus.org/browse/MNG-3602
>>>>
>>>> In the discussions surrounding that issue it was determined there
>>> would
>>>> not be enough exposure of Doxia beta-1 until the next release (at that
>>>> time). But with the new timeframe for the 2.1 release we should be
>>> able
>>>> to get good testing of Doxia beta-1.
>>>>
>>>>> 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@...
>

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

[brettporter]

I added a reference to the prototype I did earlier in the year for the  
attribute based POMs that did this using modello and stax.

I also added simplified POM syntax to the milestones for this as a  
placeholder.

- Brett

On 04/09/2008, at 8:14 AM, John Casey wrote:

> http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan
>
> Brian Fox wrote:
>> Sounds good to me
>> Sent from my iPhone
>> On Sep 3, 2008, at 5:35 PM, John Casey <jdcasey@...>  
>> wrote:
>>> Let's start another page for 2.2 features, since this one is in  
>>> the pre-planning stages still. Until we have a concrete strategy  
>>> for implementation including a design doc, I don't feel  
>>> comfortable putting it on such a near time horizon.
>>>
>>> WDYT?
>>>
>>> Brian E. Fox wrote:
>>>> The only thing I feel we need to start looking at soon is an xml  
>>>> parser
>>>> that can deal with newer models and not freak. This is probably  
>>>> related
>>>> 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 needs to be in 2.1, but maybe on the list for  
>>>> 2.2.
>>>> -----Original Message-----
>>>> From: John Casey [mailto:jdcasey@...] 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 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.
>>>>> With a timeframe of 2 months I would like to see Doxia beta-1  
>>>>> included
>>>>> in the core. This is tracked in JIRA as
>>>>> http://jira.codehaus.org/browse/MNG-3602
>>>>>
>>>>> In the discussions surrounding that issue it was determined there
>>>> would
>>>>> not be enough exposure of Doxia beta-1 until the next release  
>>>>> (at that
>>>>> time). But with the new timeframe for the 2.1 release we should be
>>>> able
>>>>> to get good testing of Doxia beta-1.
>>>>>
>>>>>> 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@...
>
> --
> 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@...
>

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[brettporter]

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 everything. I'm going to  
> contact Don Brown today and ask whether he can do a little write-up  
> for parallel resolution soonish, and I need to track down the build  
> dynamism write-up I put on Confluence (not to mention the relevant  
> JIRAs for these implementation changes). Ralph, once you have some  
> design docs for the automatic parent versioning, we'll add that in  
> as well.
>
> Please have a look, and give feedback! Thanks.
>

Looks good to me.

- Brett

--
Brett Porter
brett@...
http://blogs.exist.com/bporter/


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

[Ralph Goers]

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
> 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 to be very careful with things like cli
> arguments here, since it could have a huge impact on build
> reproducibility.
>
>

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

[Jan Fredrik Wedén]

Thank you all for the time and effort put into new Maven releases. As
a dedicated user of the tool it is much appreciated.

I see that multiple modelVersions support has made it into the 2.2
release plan. That makes me hope that some sort of global dependency
exclusion mechanism has a chance of making it into the 2.x train. I'm
currently thinking about http://jira.codehaus.org/browse/MNG-3196
which would be extremely helpful in our current corp project, but feel
free to revisit http://jira.codehaus.org/browse/MNG-1977 as well :-)

WDYT?


--
- Jan Fredrik Wedén

On Thu, Sep 4, 2008 at 12:14 AM, John Casey <jdcasey@...> wrote:

> http://docs.codehaus.org/display/MAVEN/Maven+2.2.0+Release+Plan
>
> Brian Fox wrote:
>>
>> Sounds good to me
>>
>> Sent from my iPhone
>>
>> On Sep 3, 2008, at 5:35 PM, John Casey <jdcasey@...> wrote:
>>
>>> Let's start another page for 2.2 features, since this one is in the
>>> pre-planning stages still. Until we have a concrete strategy for
>>> implementation including a design doc, I don't feel comfortable putting it
>>> on such a near time horizon.
>>>
>>> WDYT?
>>>
>>> Brian E. Fox wrote:
>>>>
>>>> The only thing I feel we need to start looking at soon is an xml parser
>>>> that can deal with newer models and not freak. This is probably related
>>>> 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 needs to be in 2.1, but maybe on the list for 2.2.
>>>> -----Original Message-----
>>>> From: John Casey [mailto:jdcasey@...] 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 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.
>>>>>
>>>>> With a timeframe of 2 months I would like to see Doxia beta-1 included
>>>>> in the core. This is tracked in JIRA as
>>>>> http://jira.codehaus.org/browse/MNG-3602
>>>>>
>>>>> In the discussions surrounding that issue it was determined there
>>>>
>>>> would
>>>>>
>>>>> not be enough exposure of Doxia beta-1 until the next release (at that
>>>>> time). But with the new timeframe for the 2.1 release we should be
>>>>
>>>> able
>>>>>
>>>>> to get good testing of Doxia beta-1.
>>>>>
>>>>>> 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@...
>>
>
> --
> 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@...