subject:"Re\: \[pre vote take 3\] 2.0.9\-RC3"

Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

plugin

  ..
  configuration
subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier

2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
 We fixed the regressions identified last week with the plugin tools
and
  reporting impl. The new 2.0.9 is staged at

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
  che-maven/2.0.9-RC3/

  You'll notice that this one has an RC qualifier attached to it. Since
  what I've actually been staging hasn't been for an official vote, it
  makes more sense to have actual deterministic numbers on them instead
of
  continuously rolling back and forth between .10 and .9.

  The other significant reason it has a qualifier is that I want to
  solicit feedback from the users list without potentially getting
  multiple versions out there called 2.0.9. My new mantra for the maven
  release is no more regressions. To that end, what I intend to do is
  let the RC sit here for a day. If no one turns up anything new (it
  should be good since this is really attempt #3), then I'll email the
  user list to solicit feedback. Naturally we'll probably get a slew of
  can you fix xyz but the only thing that we will consider at this
point
  would be a regression from 2.0.8 to the current RC. If something is
  identified then we should consider fixing it and re-releasing RC4. I
  think that having the users more involved in testing the RCs is the
only
  way to really identify and eliminate regressions. If someone
identifies
  a regression after the fact and didn't speak up or try it, well
that's
  unfortunate but it'll have to wait.

  The RC can sit with the users for 3 days. If nothing turns up, then
I'll
  restage with a final release tag and we can do a formal vote.
Assuming
  this is all successful, then I'll document a more formal Core release
  procedure that we can follow going forward.

  Here's the list of issues fixed in the latest RC:

  Release Notes - Maven 2 - Version 2.0.9

  ** Bug

 * [MNG-1412] - dependency sorting in classpath

 * [MNG-1914] - Wrong url in error message when using a mirror

 * [MNG-2123] - NullPointerException when a dependency uses version
  range and another uses an actual version incompatible with that range

 * [MNG-2145] - Plugins' dependencies are not always checked

 * [MNG-2178] - incorrect M2_HOME guess in mvn.bat

 * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
  profiles section is missing or empty

 * [MNG-2339] - ${project.*} are interpreted in the wrong place

 * [MNG-2744] - checksum comparison should be case-insensitive

 * [MNG-2809] - Can't activate a profile by checking for the
presence
  of a file in ${user.home}

 * [MNG-2848] - Environment variables in profile activation not
  working

 * [MNG-2861] - NullPointerException in DefaultArtifactCollector
for
  relocated resolvedArtifacts with different version ranges and
available
  versions.

 * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
if
  there's no mojo in pom.xml

 * [MNG-2928] - Null pointer exeception when introducing version
  range [major.minor.build-SNAPSHOT,)

 * [MNG-2972] - Ignores version of plugin dependency specified in
my
  pom

 * [MNG-3086] - NullPointerException in
  ResolutionNode.getTrail(ResolutionNode.java:136)

 * [MNG-3099] - Profiles ignored when working with non-projects
(such
  as archetype:create)

 * [MNG-3111] - Classpath order incorrect

 * [MNG-3156] - NullPointerException with mvn dependency:sources

 * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor

 * [MNG-3259] - Regression: Maven drops dependencies in
multi-module
  build

 * [MNG-3286] - execution.inherited field is ignored

 * [MNG-3288] - Invalid systemPath allows build to
continue--failing
  in later phase.

 * [MNG-3296] - mvn.bat looses error code on windows NT type
  platforms

 * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set

 * [MNG-3316] - Barfs at attribues named

Re: [pre vote take 3] 2.0.9-RC3

Hmm, I'll have to do some homework on this one, but yeah, it looks  
like the interpolation changes I put in to get the path-translation  
in place. I'll have to see if I can work up a test case for this, and  
try to track down that original issue.


Let me get to work on it and I'll see how fast I can come up with  
something.


-john

On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:


Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of

Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

plugin
  
  ..
  configuration
subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier



2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin tools

and

 reporting impl. The new 2.0.9 is staged at




http://people.apache.org/~brianf/staging-repository/org/apache/ 
maven/apa

 che-maven/2.0.9-RC3/



 You'll notice that this one has an RC qualifier attached to it.  
Since

 what I've actually been staging hasn't been for an official vote, it
 makes more sense to have actual deterministic numbers on them  
instead

of

 continuously rolling back and forth between .10 and .9.



 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the  
maven
 release is no more regressions. To that end, what I intend to  
do is

 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll email the
 user list to solicit feedback. Naturally we'll probably get a  
slew of

 can you fix xyz but the only thing that we will consider at this

point

 would be a regression from 2.0.8 to the current RC. If something is
 identified then we should consider fixing it and re-releasing RC4. I
 think that having the users more involved in testing the RCs is the

only

 way to really identify and eliminate regressions. If someone

identifies

 a regression after the fact and didn't speak up or try it, well

that's

 unfortunate but it'll have to wait.



 The RC can sit with the users for 3 days. If nothing turns up, then

I'll

 restage with a final release tag and we can do a formal vote.

Assuming
 this is all successful, then I'll document a more formal Core  
release

 procedure that we can follow going forward.



 Here's the list of issues fixed in the latest RC:



 Release Notes - Maven 2 - Version 2.0.9





 ** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when a dependency uses  
version
 range and another uses an actual version incompatible with that  
range


* [MNG-2145] - Plugins' dependencies are not always checked

* [MNG-2178] - incorrect M2_HOME guess in mvn.bat

* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored  
when

 profiles section is missing or empty

* [MNG-2339] - ${project.*} are interpreted in the wrong place

* [MNG-2744] - checksum comparison should be case-insensitive

* [MNG-2809] - Can't activate a profile by checking for the

presence

 of a file in ${user.home}

* [MNG-2848] - Environment variables in profile activation not
 working

* [MNG-2861] - NullPointerException in DefaultArtifactCollector

for

 relocated resolvedArtifacts with different version ranges and

available

 versions.

* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()

if

 there's no mojo in pom.xml

* [MNG-2928] - Null pointer exeception when introducing version
 range [major.minor.build-SNAPSHOT,)

* [MNG-2972] - Ignores version of plugin dependency specified in

my

 pom

* [MNG-3086] - NullPointerException in
 ResolutionNode.getTrail(ResolutionNode.java:136)

* [MNG-3099] - Profiles ignored when working with non-projects

(such

 as archetype:create)

* [MNG-3111] - Classpath order incorrect

* [MNG-3156] - NullPointerException with mvn dependency:sources

* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor

* [MNG-3259] - Regression: Maven

CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)


BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

// [MNG-2339] ensure the system properties are still  
interpolated for backwards compat, but the model values must win


I've checked that issue, and it looks like it was closed for this  
release...so, not present in 2.0.8. Additionally, the doesn't seem to  
say anything about which is supposed to win - model vs. sysprops.  
IMO, it makes more sense for CLI properties to override those in the  
model, since it follows the principle of local-most wins that we  
employ in other parts of Maven, but I'm not sure I know enough about  
the history of this issue.


Does anyone have another issue number that contributes more to this  
discussion, that we could use to determine the correct course of  
action here?


Thanks,

-john

On Mar 27, 2008, at 12:54 PM, John Casey wrote:
Hmm, I'll have to do some homework on this one, but yeah, it looks  
like the interpolation changes I put in to get the path-translation  
in place. I'll have to see if I can work up a test case for this,  
and try to track down that original issue.


Let me get to work on it and I'll see how fast I can come up with  
something.


-john

On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:


Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of

Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

plugin
  
  ..
  configuration
subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier



2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin tools

and

 reporting impl. The new 2.0.9 is staged at




http://people.apache.org/~brianf/staging-repository/org/apache/ 
maven/apa

 che-maven/2.0.9-RC3/



 You'll notice that this one has an RC qualifier attached to it.  
Since
 what I've actually been staging hasn't been for an official  
vote, it
 makes more sense to have actual deterministic numbers on them  
instead

of

 continuously rolling back and forth between .10 and .9.



 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the  
maven
 release is no more regressions. To that end, what I intend to  
do is

 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll email  
the
 user list to solicit feedback. Naturally we'll probably get a  
slew of

 can you fix xyz but the only thing that we will consider at this

point

 would be a regression from 2.0.8 to the current RC. If something is
 identified then we should consider fixing it and re-releasing  
RC4. I

 think that having the users more involved in testing the RCs is the

only

 way to really identify and eliminate regressions. If someone

identifies

 a regression after the fact and didn't speak up or try it, well

that's

 unfortunate but it'll have to wait.



 The RC can sit with the users for 3 days. If nothing turns up, then

I'll

 restage with a final release tag and we can do a formal vote.

Assuming
 this is all successful, then I'll document a more formal Core  
release

 procedure that we can follow going forward.



 Here's the list of issues fixed in the latest RC:



 Release Notes - Maven 2 - Version 2.0.9





 ** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when a dependency uses  
version
 range and another uses an actual version incompatible with that  
range


* [MNG-2145] - Plugins' dependencies are not always checked

* [MNG-2178] - incorrect M2_HOME guess in mvn.bat

* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored  
when

 profiles section is missing or empty

* [MNG-2339] - ${project.*} are interpreted in the wrong place

* [MNG-2744] - checksum comparison should be case-insensitive

* [MNG-2809] - Can't activate a profile by checking for the

presence

 of a file in ${user.home}

* [MNG-2848] - Environment variables in profile activation

Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)


Sorry for the spam.

Digging deeper through the related links on MNG-2339, it's apparent  
that the comment in the DefaultMavenProjectBuilder is a touch  
misleading. The key issues relevant to where sysprops get used during  
interpolation are:


MNG-2745
MNG-2651

It seems that environments that use maven programmatically (in 2.0.x?  
really??) are running into collisions where other libraries are  
injecting system properties that override values from the POM for the  
purposes of interpolation. For this reason (and because we don't have  
a concept of CLI properties separate from sysprops yet), the code in  
the project builder was changed to prefer values from the POM over  
sysprops.


-john

On Mar 27, 2008, at 1:06 PM, John Casey wrote:


BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

// [MNG-2339] ensure the system properties are still  
interpolated for backwards compat, but the model values must win


I've checked that issue, and it looks like it was closed for this  
release...so, not present in 2.0.8. Additionally, the doesn't seem  
to say anything about which is supposed to win - model vs.  
sysprops. IMO, it makes more sense for CLI properties to override  
those in the model, since it follows the principle of local-most  
wins that we employ in other parts of Maven, but I'm not sure I  
know enough about the history of this issue.


Does anyone have another issue number that contributes more to this  
discussion, that we could use to determine the correct course of  
action here?


Thanks,

-john

On Mar 27, 2008, at 12:54 PM, John Casey wrote:
Hmm, I'll have to do some homework on this one, but yeah, it looks  
like the interpolation changes I put in to get the path- 
translation in place. I'll have to see if I can work up a test  
case for this, and try to track down that original issue.


Let me get to work on it and I'll see how fast I can come up with  
something.


-john

On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:


Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
Behalf Of

Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

plugin
  
  ..
  configuration
subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier



2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin tools

and

 reporting impl. The new 2.0.9 is staged at




http://people.apache.org/~brianf/staging-repository/org/apache/ 
maven/apa

 che-maven/2.0.9-RC3/



 You'll notice that this one has an RC qualifier attached to it.  
Since
 what I've actually been staging hasn't been for an official  
vote, it
 makes more sense to have actual deterministic numbers on them  
instead

of

 continuously rolling back and forth between .10 and .9.



 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the  
maven
 release is no more regressions. To that end, what I intend to  
do is

 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll  
email the
 user list to solicit feedback. Naturally we'll probably get a  
slew of

 can you fix xyz but the only thing that we will consider at this

point
 would be a regression from 2.0.8 to the current RC. If  
something is
 identified then we should consider fixing it and re-releasing  
RC4. I
 think that having the users more involved in testing the RCs is  
the

only

 way to really identify and eliminate regressions. If someone

identifies

 a regression after the fact and didn't speak up or try it, well

that's

 unfortunate but it'll have to wait.



 The RC can sit with the users for 3 days. If nothing turns up,  
then

I'll

 restage with a final release tag and we can do a formal vote.

Assuming
 this is all successful, then I'll document a more formal Core  
release

 procedure that we can follow going forward.



 Here's the list of issues fixed in the latest RC:



 Release Notes - Maven 2 - Version 2.0.9





 ** Bug

* [MNG-1412] - dependency sorting

RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

CLI should win. There was an issue open that I wrote for that a while
ago. I think it's still open even.

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 27, 2008 1:07 PM
To: Maven Developers List
Subject: CLI Properties vs. Model Properties (Was Re: [pre vote take 3]
2.0.9-RC3)

BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

 // [MNG-2339] ensure the system properties are still  
interpolated for backwards compat, but the model values must win

I've checked that issue, and it looks like it was closed for this  
release...so, not present in 2.0.8. Additionally, the doesn't seem to  
say anything about which is supposed to win - model vs. sysprops.  
IMO, it makes more sense for CLI properties to override those in the  
model, since it follows the principle of local-most wins that we  
employ in other parts of Maven, but I'm not sure I know enough about  
the history of this issue.

Does anyone have another issue number that contributes more to this  
discussion, that we could use to determine the correct course of  
action here?

Thanks,

-john

On Mar 27, 2008, at 12:54 PM, John Casey wrote:
 Hmm, I'll have to do some homework on this one, but yeah, it looks  
 like the interpolation changes I put in to get the path-translation  
 in place. I'll have to see if I can work up a test case for this,  
 and try to track down that original issue.

 Let me get to work on it and I'll see how fast I can come up with  
 something.

 -john

 On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:

 Hrm. It's probably a good idea to use a different property, but we
 should understand why this changed before going further. John, any
 ideas?

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
 Behalf Of
 Olivier Lamy
 Sent: Thursday, March 27, 2008 6:56 AM
 To: Maven Developers List
 Subject: Re: [pre vote take 3] 2.0.9-RC3

 Hi,
 Testing on corporate projects and build fine.
 +1

 I have just noticed a change (regression ?).
 We have a corporate plugin. In the pom it's configured as this :

 plugin

   ..
   configuration
 subject.. - ${version} ../subject

 We use it with mvn blabla -Dversion=here a version.
 The value has changed :
 - with mvn 2.0.8 : the value from the cli is used.
 - with this RC : the ${version} is replaced with the current
 pom.version.

 It's not a blocking issue because we can easily replace with :
 subject.. - ${releaseVersion} ../subject and use  mvn blabla
 -DreleaseVersion=

 But I hope there is no other side effect.

 --
 Olivier

 2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
 We fixed the regressions identified last week with the plugin tools
 and
  reporting impl. The new 2.0.9 is staged at

 http://people.apache.org/~brianf/staging-repository/org/apache/ 
 maven/apa
  che-maven/2.0.9-RC3/

  You'll notice that this one has an RC qualifier attached to it.  
 Since
  what I've actually been staging hasn't been for an official  
 vote, it
  makes more sense to have actual deterministic numbers on them  
 instead
 of
  continuously rolling back and forth between .10 and .9.

  The other significant reason it has a qualifier is that I want to
  solicit feedback from the users list without potentially getting
  multiple versions out there called 2.0.9. My new mantra for the  
 maven
  release is no more regressions. To that end, what I intend to  
 do is
  let the RC sit here for a day. If no one turns up anything new (it
  should be good since this is really attempt #3), then I'll email  
 the
  user list to solicit feedback. Naturally we'll probably get a  
 slew of
  can you fix xyz but the only thing that we will consider at this
 point
  would be a regression from 2.0.8 to the current RC. If something is
  identified then we should consider fixing it and re-releasing  
 RC4. I
  think that having the users more involved in testing the RCs is the
 only
  way to really identify and eliminate regressions. If someone
 identifies
  a regression after the fact and didn't speak up or try it, well
 that's
  unfortunate but it'll have to wait.

  The RC can sit with the users for 3 days. If nothing turns up, then
 I'll
  restage with a final release tag and we can do a formal vote.
 Assuming
  this is all successful, then I'll document a more formal Core  
 release
  procedure that we can follow going forward.

  Here's the list of issues fixed in the latest RC:

  Release Notes - Maven 2 - Version 2.0.9

  ** Bug

 * [MNG-1412] - dependency sorting in classpath

 * [MNG-1914] - Wrong url in error message when using a mirror

 * [MNG-2123] - NullPointerException when a dependency uses  
 version
  range and another uses an actual version incompatible with that  
 range

 * [MNG-2145] - Plugins' dependencies are not always checked

 * [MNG-2178] - incorrect M2_HOME guess in mvn.bat

 * [MNG-2234

RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

We have to err on the side of not causing more regressions. If we want
to move in this direction, we should start deprecating the non
${project. Forms of the properties with big warnings in 2.0.9.

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 27, 2008 1:16 PM
To: Maven Developers List
Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take
3] 2.0.9-RC3)

Sorry for the spam.

Digging deeper through the related links on MNG-2339, it's apparent  
that the comment in the DefaultMavenProjectBuilder is a touch  
misleading. The key issues relevant to where sysprops get used during  
interpolation are:

MNG-2745
MNG-2651

It seems that environments that use maven programmatically (in 2.0.x?  
really??) are running into collisions where other libraries are  
injecting system properties that override values from the POM for the  
purposes of interpolation. For this reason (and because we don't have  
a concept of CLI properties separate from sysprops yet), the code in  
the project builder was changed to prefer values from the POM over  
sysprops.

-john

On Mar 27, 2008, at 1:06 PM, John Casey wrote:

 BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

 // [MNG-2339] ensure the system properties are still  
 interpolated for backwards compat, but the model values must win

 I've checked that issue, and it looks like it was closed for this  
 release...so, not present in 2.0.8. Additionally, the doesn't seem  
 to say anything about which is supposed to win - model vs.  
 sysprops. IMO, it makes more sense for CLI properties to override  
 those in the model, since it follows the principle of local-most  
 wins that we employ in other parts of Maven, but I'm not sure I  
 know enough about the history of this issue.

 Does anyone have another issue number that contributes more to this  
 discussion, that we could use to determine the correct course of  
 action here?

 Thanks,

 -john

 On Mar 27, 2008, at 12:54 PM, John Casey wrote:
 Hmm, I'll have to do some homework on this one, but yeah, it looks  
 like the interpolation changes I put in to get the path- 
 translation in place. I'll have to see if I can work up a test  
 case for this, and try to track down that original issue.

 Let me get to work on it and I'll see how fast I can come up with  
 something.

 -john

 On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:

 Hrm. It's probably a good idea to use a different property, but we
 should understand why this changed before going further. John, any
 ideas?

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On  
 Behalf Of
 Olivier Lamy
 Sent: Thursday, March 27, 2008 6:56 AM
 To: Maven Developers List
 Subject: Re: [pre vote take 3] 2.0.9-RC3

 Hi,
 Testing on corporate projects and build fine.
 +1

 I have just noticed a change (regression ?).
 We have a corporate plugin. In the pom it's configured as this :

 plugin

   ..
   configuration
 subject.. - ${version} ../subject

 We use it with mvn blabla -Dversion=here a version.
 The value has changed :
 - with mvn 2.0.8 : the value from the cli is used.
 - with this RC : the ${version} is replaced with the current
 pom.version.

 It's not a blocking issue because we can easily replace with :
 subject.. - ${releaseVersion} ../subject and use  mvn blabla
 -DreleaseVersion=

 But I hope there is no other side effect.

 --
 Olivier

 2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
 We fixed the regressions identified last week with the plugin tools
 and
  reporting impl. The new 2.0.9 is staged at

 http://people.apache.org/~brianf/staging-repository/org/apache/ 
 maven/apa
  che-maven/2.0.9-RC3/

  You'll notice that this one has an RC qualifier attached to it.  
 Since
  what I've actually been staging hasn't been for an official  
 vote, it
  makes more sense to have actual deterministic numbers on them  
 instead
 of
  continuously rolling back and forth between .10 and .9.

  The other significant reason it has a qualifier is that I want to
  solicit feedback from the users list without potentially getting
  multiple versions out there called 2.0.9. My new mantra for the  
 maven
  release is no more regressions. To that end, what I intend to  
 do is
  let the RC sit here for a day. If no one turns up anything new (it
  should be good since this is really attempt #3), then I'll  
 email the
  user list to solicit feedback. Naturally we'll probably get a  
 slew of
  can you fix xyz but the only thing that we will consider at this
 point
  would be a regression from 2.0.8 to the current RC. If  
 something is
  identified then we should consider fixing it and re-releasing  
 RC4. I
  think that having the users more involved in testing the RCs is  
 the
 only
  way to really identify and eliminate regressions. If someone
 identifies
  a regression after the fact and didn't speak up

Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

I was incorrect; this is not a result of code I changed. I'll have to  
take a look at the SVN annotation to find the commit that changed  
this, but it looks like it may have been part of some work Jason was  
doing. I'm looking into it now.


-john

On Mar 27, 2008, at 1:19 PM, Brian E. Fox wrote:


We have to err on the side of not causing more regressions. If we want
to move in this direction, we should start deprecating the non
${project. Forms of the properties with big warnings in 2.0.9.

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 1:16 PM
To: Maven Developers List
Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote  
take

3] 2.0.9-RC3)

Sorry for the spam.

Digging deeper through the related links on MNG-2339, it's apparent
that the comment in the DefaultMavenProjectBuilder is a touch
misleading. The key issues relevant to where sysprops get used during
interpolation are:

MNG-2745
MNG-2651

It seems that environments that use maven programmatically (in 2.0.x?
really??) are running into collisions where other libraries are
injecting system properties that override values from the POM for the
purposes of interpolation. For this reason (and because we don't have
a concept of CLI properties separate from sysprops yet), the code in
the project builder was changed to prefer values from the POM over
sysprops.

-john

On Mar 27, 2008, at 1:06 PM, John Casey wrote:


BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

// [MNG-2339] ensure the system properties are still
interpolated for backwards compat, but the model values must win

I've checked that issue, and it looks like it was closed for this
release...so, not present in 2.0.8. Additionally, the doesn't seem
to say anything about which is supposed to win - model vs.
sysprops. IMO, it makes more sense for CLI properties to override
those in the model, since it follows the principle of local-most
wins that we employ in other parts of Maven, but I'm not sure I
know enough about the history of this issue.

Does anyone have another issue number that contributes more to this
discussion, that we could use to determine the correct course of
action here?

Thanks,

-john

On Mar 27, 2008, at 12:54 PM, John Casey wrote:

Hmm, I'll have to do some homework on this one, but yeah, it looks
like the interpolation changes I put in to get the path-
translation in place. I'll have to see if I can work up a test
case for this, and try to track down that original issue.

Let me get to work on it and I'll see how fast I can come up with
something.

-john

On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:


Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

plugin
  
  ..
  configuration
subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier



2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
We fixed the regressions identified last week with the plugin  
tools

and

 reporting impl. The new 2.0.9 is staged at





http://people.apache.org/~brianf/staging-repository/org/apache/
maven/apa

 che-maven/2.0.9-RC3/



 You'll notice that this one has an RC qualifier attached to it.
Since
 what I've actually been staging hasn't been for an official
vote, it
 makes more sense to have actual deterministic numbers on them
instead

of

 continuously rolling back and forth between .10 and .9.



 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the
maven
 release is no more regressions. To that end, what I intend to
do is
 let the RC sit here for a day. If no one turns up anything new  
(it

 should be good since this is really attempt #3), then I'll
email the
 user list to solicit feedback. Naturally we'll probably get a
slew of
 can you fix xyz but the only thing that we will consider at  
this

point

 would be a regression from 2.0.8 to the current RC. If
something is
 identified then we should consider fixing it and re-releasing
RC4. I
 think that having the users

Re: [pre vote take 3] 2.0.9-RC3

2008-03-27 Thread Daniel Kulp



I'm seeing a regression in CXF builds with 2.0.9-RC3.   I cannot do a
deploy.   One of the CXF poms is probably not setup completely optimal,
but it works for 2.0.6-2.0.8.   

Basically, for some reason, it ends up running javadoc twice.  With 2.0.8,
that's fine.  With 2.0.9, I get:

[INFO] Building jar:
/home/dkulp/working/cxf/api/target/cxf-api-2.1-incubator-SNAPSHOT-javadoc.jar
[WARNING] Duplicate artifact attachment detected. (project:
org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment:
org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT)
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error attaching artifact to project: Duplicate attachment.

Embedded error: Duplicate artifact attachment detected. (project:
org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment:
org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT)
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]


Dan



Brian E Fox wrote:
 
 We fixed the regressions identified last week with the plugin tools and
 reporting impl. The new 2.0.9 is staged at 
 
  
 
 http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
 che-maven/2.0.9-RC3/
 
  
 
 You'll notice that this one has an RC qualifier attached to it. Since
 what I've actually been staging hasn't been for an official vote, it
 makes more sense to have actual deterministic numbers on them instead of
 continuously rolling back and forth between .10 and .9.
 
  
 
 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the maven
 release is no more regressions. To that end, what I intend to do is
 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll email the
 user list to solicit feedback. Naturally we'll probably get a slew of
 can you fix xyz but the only thing that we will consider at this point
 would be a regression from 2.0.8 to the current RC. If something is
 identified then we should consider fixing it and re-releasing RC4. I
 think that having the users more involved in testing the RCs is the only
 way to really identify and eliminate regressions. If someone identifies
 a regression after the fact and didn't speak up or try it, well that's
 unfortunate but it'll have to wait.
 
  
 
 The RC can sit with the users for 3 days. If nothing turns up, then I'll
 restage with a final release tag and we can do a formal vote. Assuming
 this is all successful, then I'll document a more formal Core release
 procedure that we can follow going forward.
 
  
 
 Here's the list of issues fixed in the latest RC:
 
  
 
 Release Notes - Maven 2 - Version 2.0.9
 
  
 
  
 
 ** Bug
 
 * [MNG-1412] - dependency sorting in classpath
 
 * [MNG-1914] - Wrong url in error message when using a mirror
 
 * [MNG-2123] - NullPointerException when a dependency uses version
 range and another uses an actual version incompatible with that range
 
 * [MNG-2145] - Plugins' dependencies are not always checked
 
 * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
 
 * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
 profiles section is missing or empty
 
 * [MNG-2339] - ${project.*} are interpreted in the wrong place
 
 * [MNG-2744] - checksum comparison should be case-insensitive
 
 * [MNG-2809] - Can't activate a profile by checking for the presence
 of a file in ${user.home}
 
 * [MNG-2848] - Environment variables in profile activation not
 working
 
 * [MNG-2861] - NullPointerException in DefaultArtifactCollector for
 relocated resolvedArtifacts with different version ranges and available
 versions.
 
 * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
 there's no mojo in pom.xml
 
 * [MNG-2928] - Null pointer exeception when introducing version
 range [major.minor.build-SNAPSHOT,)
 
 * [MNG-2972] - Ignores version of plugin dependency specified in my
 pom
 
 * [MNG-3086] - NullPointerException in
 ResolutionNode.getTrail(ResolutionNode.java:136)
 
 * [MNG-3099] - Profiles ignored when working with non-projects (such
 as archetype:create)
 
 * [MNG-3111] - Classpath order incorrect
 
 * [MNG-3156] - NullPointerException with mvn dependency:sources
 
 * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
 
 * [MNG-3259] - Regression: Maven drops dependencies in multi-module
 build
 
 * [MNG-3286] - execution.inherited field is ignored
 
 * [MNG-3288] - Invalid systemPath allows build to continue--failing
 in

Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

2008-03-27 Thread Brett Porter

I changed it, and it was in http://jira.codehaus.org/browse/MNG-2339  
as the comment says.


JDK 1.4 defines a system property for version that is 2.4.1 for  
some reason, and it wreaks havoc on anything that uses ${version}, $ 
{project.version}, etc.


I can't see why overriding model values makes any sense from the  
command line - that's not what Olivier wanted but rather a straight  
substitution.


The only change I can think of here is to have previous behaviour from  
${version} and make sure ${project.version} is unaffected, but that's  
a significant change to the interpolator.


I think we're better off leaving this fix in with something in the  
release notes.


- Brett

On 28/03/2008, at 4:49 AM, John Casey wrote:

I was incorrect; this is not a result of code I changed. I'll have  
to take a look at the SVN annotation to find the commit that changed  
this, but it looks like it may have been part of some work Jason was  
doing. I'm looking into it now.


-john

On Mar 27, 2008, at 1:19 PM, Brian E. Fox wrote:

We have to err on the side of not causing more regressions. If we  
want

to move in this direction, we should start deprecating the non
${project. Forms of the properties with big warnings in 2.0.9.

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 1:16 PM
To: Maven Developers List
Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote  
take

3] 2.0.9-RC3)

Sorry for the spam.

Digging deeper through the related links on MNG-2339, it's apparent
that the comment in the DefaultMavenProjectBuilder is a touch
misleading. The key issues relevant to where sysprops get used during
interpolation are:

MNG-2745
MNG-2651

It seems that environments that use maven programmatically (in 2.0.x?
really??) are running into collisions where other libraries are
injecting system properties that override values from the POM for the
purposes of interpolation. For this reason (and because we don't have
a concept of CLI properties separate from sysprops yet), the code in
the project builder was changed to prefer values from the POM over
sysprops.

-john

On Mar 27, 2008, at 1:06 PM, John Casey wrote:


BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

   // [MNG-2339] ensure the system properties are still
interpolated for backwards compat, but the model values must win

I've checked that issue, and it looks like it was closed for this
release...so, not present in 2.0.8. Additionally, the doesn't seem
to say anything about which is supposed to win - model vs.
sysprops. IMO, it makes more sense for CLI properties to override
those in the model, since it follows the principle of local-most
wins that we employ in other parts of Maven, but I'm not sure I
know enough about the history of this issue.

Does anyone have another issue number that contributes more to this
discussion, that we could use to determine the correct course of
action here?

Thanks,

-john

On Mar 27, 2008, at 12:54 PM, John Casey wrote:

Hmm, I'll have to do some homework on this one, but yeah, it looks
like the interpolation changes I put in to get the path-
translation in place. I'll have to see if I can work up a test
case for this, and try to track down that original issue.

Let me get to work on it and I'll see how fast I can come up with
something.

-john

On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:


Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

   plugin
 
 ..
 configuration
   subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier



2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
We fixed the regressions identified last week with the plugin  
tools

and

reporting impl. The new 2.0.9 is staged at





http://people.apache.org/~brianf/staging-repository/org/apache/
maven/apa

che-maven/2.0.9-RC3/



You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official
vote, it
makes more sense to have actual deterministic numbers on them
instead

of

continuously rolling back and forth between .10 and .9

RE: [pre vote take 3] 2.0.9-RC3

Hi Dan, we saw that last night, try the RC4-SNAPSHOT:
http://people.apache.org/~brianf

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 27, 2008 2:54 PM
To: dev@maven.apache.org
Subject: Re: [pre vote take 3] 2.0.9-RC3

I'm seeing a regression in CXF builds with 2.0.9-RC3.   I cannot do a
deploy.   One of the CXF poms is probably not setup completely
optimal,
but it works for 2.0.6-2.0.8.   

Basically, for some reason, it ends up running javadoc twice.  With
2.0.8,
that's fine.  With 2.0.9, I get:

[INFO] Building jar:
/home/dkulp/working/cxf/api/target/cxf-api-2.1-incubator-SNAPSHOT-javado
c.jar
[WARNING] Duplicate artifact attachment detected. (project:
org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment:
org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT)
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] Error attaching artifact to project: Duplicate attachment.

Embedded error: Duplicate artifact attachment detected. (project:
org.apache.cxf:cxf-api:jar:2.1-incubator-SNAPSHOT; illegal attachment:
org.apache.cxf:cxf-api:javadoc:javadoc:2.1-incubator-SNAPSHOT)
[INFO]

[INFO] For more information, run Maven with the -e switch
[INFO]

Dan

Brian E Fox wrote:

 We fixed the regressions identified last week with the plugin tools
and
 reporting impl. The new 2.0.9 is staged at 

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
 che-maven/2.0.9-RC3/

 You'll notice that this one has an RC qualifier attached to it. Since
 what I've actually been staging hasn't been for an official vote, it
 makes more sense to have actual deterministic numbers on them instead
of
 continuously rolling back and forth between .10 and .9.

 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the maven
 release is no more regressions. To that end, what I intend to do is
 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll email the
 user list to solicit feedback. Naturally we'll probably get a slew of
 can you fix xyz but the only thing that we will consider at this
point
 would be a regression from 2.0.8 to the current RC. If something is
 identified then we should consider fixing it and re-releasing RC4. I
 think that having the users more involved in testing the RCs is the
only
 way to really identify and eliminate regressions. If someone
identifies
 a regression after the fact and didn't speak up or try it, well that's
 unfortunate but it'll have to wait.

 The RC can sit with the users for 3 days. If nothing turns up, then
I'll
 restage with a final release tag and we can do a formal vote. Assuming
 this is all successful, then I'll document a more formal Core release
 procedure that we can follow going forward.

 Here's the list of issues fixed in the latest RC:

 Release Notes - Maven 2 - Version 2.0.9

 ** Bug

 * [MNG-1412] - dependency sorting in classpath

 * [MNG-1914] - Wrong url in error message when using a mirror

 * [MNG-2123] - NullPointerException when a dependency uses version
 range and another uses an actual version incompatible with that range

 * [MNG-2145] - Plugins' dependencies are not always checked

 * [MNG-2178] - incorrect M2_HOME guess in mvn.bat

 * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
 profiles section is missing or empty

 * [MNG-2339] - ${project.*} are interpreted in the wrong place

 * [MNG-2744] - checksum comparison should be case-insensitive

 * [MNG-2809] - Can't activate a profile by checking for the
presence
 of a file in ${user.home}

 * [MNG-2848] - Environment variables in profile activation not
 working

 * [MNG-2861] - NullPointerException in DefaultArtifactCollector
for
 relocated resolvedArtifacts with different version ranges and
available
 versions.

 * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
if
 there's no mojo in pom.xml

 * [MNG-2928] - Null pointer exeception when introducing version
 range [major.minor.build-SNAPSHOT,)

 * [MNG-2972] - Ignores version of plugin dependency specified in
my
 pom

 * [MNG-3086] - NullPointerException in
 ResolutionNode.getTrail(ResolutionNode.java:136)

 * [MNG-3099] - Profiles ignored when working with non-projects
(such
 as archetype:create)

 * [MNG-3111] - Classpath order incorrect

 * [MNG-3156] - NullPointerException with mvn dependency:sources

 * [MNG

RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)


I can't see why overriding model values makes any sense from the  
command line - that's not what Olivier wanted but rather a straight  
substitution.

You shouldn't be able to override model values for sure. I was saying
that if something is defined on the CLI for everything else, it should
take precedence.

The only change I can think of here is to have previous behaviour from

${version} and make sure ${project.version} is unaffected, but that's  
a significant change to the interpolator.

That's not promising.

I think we're better off leaving this fix in with something in the  
release notes.

I don't. We need to stop shoving incompatible changes down the user's
throats. It shouldn't always require reworking of your poms to upgrade
to the next maven version. That's annoying and wrong. If we do need to
make changes, and I agree that forward progress must be made that
sometimes breaks stuff, it should be deprecated first so people can get
a chance to fix their poms.

Based on the votes and comments in the issue, it's clear we can't just
revert it either...We need to fix this correctly. 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

2008-03-27 Thread Paul Benedict

Brian, what do you consider the correct fix? That CLI takes precedence over
POM properties? I was trying to glean through this chain to find out your
proposal.

Paul

On Thu, Mar 27, 2008 at 2:08 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:


 I can't see why overriding model values makes any sense from the
 command line - that's not what Olivier wanted but rather a straight
 substitution.

 You shouldn't be able to override model values for sure. I was saying
 that if something is defined on the CLI for everything else, it should
 take precedence.

 The only change I can think of here is to have previous behaviour from

 ${version} and make sure ${project.version} is unaffected, but that's
 a significant change to the interpolator.

 That's not promising.

 I think we're better off leaving this fix in with something in the
 release notes.

 I don't. We need to stop shoving incompatible changes down the user's
 throats. It shouldn't always require reworking of your poms to upgrade
 to the next maven version. That's annoying and wrong. If we do need to
 make changes, and I agree that forward progress must be made that
 sometimes breaks stuff, it should be deprecated first so people can get
 a chance to fix their poms.

 Based on the votes and comments in the issue, it's clear we can't just
 revert it either...We need to fix this correctly.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

2008-03-27 Thread Brett Porter



On 28/03/2008, at 6:37 AM, Paul Benedict wrote:

Brian, what do you consider the correct fix? That CLI takes  
precedence over
POM properties? I was trying to glean through this chain to find out  
your

proposal.


The most correct fix is:
a) -Dversion should still replace ${version}
b) -Dversion should not replace ${project.version}
c) ${version} should evaluate to ${project.version} if nothing else  
specified (though this should be deprecated behaviour).


The same applies for every other pom property, not just version.

The problem with my fix is that (a) no longer holds, though reverting  
would sacrifice (b).


On IRC, John said he has a potential fix that makes (a) hold, and  
while (b) doesn't, it mitigates the main observed side effect which is  
-Dversion coming in from the environment, rather than the command  
line. This is the least risk, but it's also another new behaviour we  
may not want to preserve.


Fixing (a) + (b) is possible, but also risks some other regression in  
(c).


- Brett

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

We're actively discussing on IRC, but in my mind a correct fix is one
that fixes the root of the jira, which is that system properties where
hosing versions, and doesn't break more builds.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Benedict
Sent: Thursday, March 27, 2008 3:38 PM
To: Maven Developers List
Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote take
3] 2.0.9-RC3)

Brian, what do you consider the correct fix? That CLI takes precedence
over
POM properties? I was trying to glean through this chain to find out
your
proposal.

Paul

On Thu, Mar 27, 2008 at 2:08 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:

 I can't see why overriding model values makes any sense from the
 command line - that's not what Olivier wanted but rather a straight
 substitution.

 You shouldn't be able to override model values for sure. I was saying
 that if something is defined on the CLI for everything else, it should
 take precedence.

 The only change I can think of here is to have previous behaviour
from

 ${version} and make sure ${project.version} is unaffected, but that's
 a significant change to the interpolator.

 That's not promising.

 I think we're better off leaving this fix in with something in the
 release notes.

 I don't. We need to stop shoving incompatible changes down the user's
 throats. It shouldn't always require reworking of your poms to upgrade
 to the next maven version. That's annoying and wrong. If we do need to
 make changes, and I agree that forward progress must be made that
 sometimes breaks stuff, it should be deprecated first so people can
get
 a chance to fix their poms.

 Based on the votes and comments in the issue, it's clear we can't just
 revert it either...We need to fix this correctly.

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)

2008-03-27 Thread Jason van Zyl

There should be absolutely no system properties manipulation in the  
bowels of Maven. Or envars, they both need to be trapped at the front- 
end because we end up with little bits here and there. They should all  
be grabbed from the CLI, the order of precedence determined and then  
passed into Maven as properties. All the system properties and envar  
need to be entirely contained to the CLI. That's the direction I've  
been moving in. Even if we obey things like ${ENV.foo} that should be  
a property not operating on envars directly in the core.


On 27-Mar-08, at 10:49 AM, John Casey wrote:
I was incorrect; this is not a result of code I changed. I'll have  
to take a look at the SVN annotation to find the commit that changed  
this, but it looks like it may have been part of some work Jason was  
doing. I'm looking into it now.


-john

On Mar 27, 2008, at 1:19 PM, Brian E. Fox wrote:

We have to err on the side of not causing more regressions. If we  
want

to move in this direction, we should start deprecating the non
${project. Forms of the properties with big warnings in 2.0.9.

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 27, 2008 1:16 PM
To: Maven Developers List
Subject: Re: CLI Properties vs. Model Properties (Was Re: [pre vote  
take

3] 2.0.9-RC3)

Sorry for the spam.

Digging deeper through the related links on MNG-2339, it's apparent
that the comment in the DefaultMavenProjectBuilder is a touch
misleading. The key issues relevant to where sysprops get used during
interpolation are:

MNG-2745
MNG-2651

It seems that environments that use maven programmatically (in 2.0.x?
really??) are running into collisions where other libraries are
injecting system properties that override values from the POM for the
purposes of interpolation. For this reason (and because we don't have
a concept of CLI properties separate from sysprops yet), the code in
the project builder was changed to prefer values from the POM over
sysprops.

-john

On Mar 27, 2008, at 1:06 PM, John Casey wrote:


BTW, I found this comment on line 981 of DefaultMavenProjectBuilder:

   // [MNG-2339] ensure the system properties are still
interpolated for backwards compat, but the model values must win

I've checked that issue, and it looks like it was closed for this
release...so, not present in 2.0.8. Additionally, the doesn't seem
to say anything about which is supposed to win - model vs.
sysprops. IMO, it makes more sense for CLI properties to override
those in the model, since it follows the principle of local-most
wins that we employ in other parts of Maven, but I'm not sure I
know enough about the history of this issue.

Does anyone have another issue number that contributes more to this
discussion, that we could use to determine the correct course of
action here?

Thanks,

-john

On Mar 27, 2008, at 12:54 PM, John Casey wrote:

Hmm, I'll have to do some homework on this one, but yeah, it looks
like the interpolation changes I put in to get the path-
translation in place. I'll have to see if I can work up a test
case for this, and try to track down that original issue.

Let me get to work on it and I'll see how fast I can come up with
something.

-john

On Mar 27, 2008, at 8:09 AM, Brian E. Fox wrote:


Hrm. It's probably a good idea to use a different property, but we
should understand why this changed before going further. John, any
ideas?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Olivier Lamy
Sent: Thursday, March 27, 2008 6:56 AM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Hi,
Testing on corporate projects and build fine.
+1

I have just noticed a change (regression ?).
We have a corporate plugin. In the pom it's configured as this :

   plugin
 
 ..
 configuration
   subject.. - ${version} ../subject

We use it with mvn blabla -Dversion=here a version.
The value has changed :
- with mvn 2.0.8 : the value from the cli is used.
- with this RC : the ${version} is replaced with the current
pom.version.

It's not a blocking issue because we can easily replace with :
subject.. - ${releaseVersion} ../subject and use  mvn blabla
-DreleaseVersion=

But I hope there is no other side effect.

--
Olivier



2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
We fixed the regressions identified last week with the plugin  
tools

and

reporting impl. The new 2.0.9 is staged at





http://people.apache.org/~brianf/staging-repository/org/apache/
maven/apa

che-maven/2.0.9-RC3/



You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official
vote, it
makes more sense to have actual deterministic numbers on them
instead

of

continuously rolling back and forth between .10 and .9.



The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple

Re: [pre vote take 3] 2.0.9-RC3

2008-03-27 Thread James William Dumay

I've been testing the Wagon Webdav module in the current release
candidate - there are a few glitches to do with the graceful handling of
redirects.

See WAGON-103 for more details.

I recommend that we should retract this from core for the 2.0.9 release.

James

On Thu, 2008-03-27 at 11:48 +0100, Fabrice Bellingard wrote:
 Tested on my projects, works fine.
 
 Here's my +1 for RC4.
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [pre vote take 3] 2.0.9-RC3

2008-03-26 Thread Raphaël Piéroni

+1 for the new process.
not yet tested the bundle.

Raphaël

2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
 We fixed the regressions identified last week with the plugin tools and
  reporting impl. The new 2.0.9 is staged at



  http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
  che-maven/2.0.9-RC3/



  You'll notice that this one has an RC qualifier attached to it. Since
  what I've actually been staging hasn't been for an official vote, it
  makes more sense to have actual deterministic numbers on them instead of
  continuously rolling back and forth between .10 and .9.



  The other significant reason it has a qualifier is that I want to
  solicit feedback from the users list without potentially getting
  multiple versions out there called 2.0.9. My new mantra for the maven
  release is no more regressions. To that end, what I intend to do is
  let the RC sit here for a day. If no one turns up anything new (it
  should be good since this is really attempt #3), then I'll email the
  user list to solicit feedback. Naturally we'll probably get a slew of
  can you fix xyz but the only thing that we will consider at this point
  would be a regression from 2.0.8 to the current RC. If something is
  identified then we should consider fixing it and re-releasing RC4. I
  think that having the users more involved in testing the RCs is the only
  way to really identify and eliminate regressions. If someone identifies
  a regression after the fact and didn't speak up or try it, well that's
  unfortunate but it'll have to wait.



  The RC can sit with the users for 3 days. If nothing turns up, then I'll
  restage with a final release tag and we can do a formal vote. Assuming
  this is all successful, then I'll document a more formal Core release
  procedure that we can follow going forward.



  Here's the list of issues fixed in the latest RC:



  Release Notes - Maven 2 - Version 2.0.9





  ** Bug

 * [MNG-1412] - dependency sorting in classpath

 * [MNG-1914] - Wrong url in error message when using a mirror

 * [MNG-2123] - NullPointerException when a dependency uses version
  range and another uses an actual version incompatible with that range

 * [MNG-2145] - Plugins' dependencies are not always checked

 * [MNG-2178] - incorrect M2_HOME guess in mvn.bat

 * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
  profiles section is missing or empty

 * [MNG-2339] - ${project.*} are interpreted in the wrong place

 * [MNG-2744] - checksum comparison should be case-insensitive

 * [MNG-2809] - Can't activate a profile by checking for the presence
  of a file in ${user.home}

 * [MNG-2848] - Environment variables in profile activation not
  working

 * [MNG-2861] - NullPointerException in DefaultArtifactCollector for
  relocated resolvedArtifacts with different version ranges and available
  versions.

 * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
  there's no mojo in pom.xml

 * [MNG-2928] - Null pointer exeception when introducing version
  range [major.minor.build-SNAPSHOT,)

 * [MNG-2972] - Ignores version of plugin dependency specified in my
  pom

 * [MNG-3086] - NullPointerException in
  ResolutionNode.getTrail(ResolutionNode.java:136)

 * [MNG-3099] - Profiles ignored when working with non-projects (such
  as archetype:create)

 * [MNG-3111] - Classpath order incorrect

 * [MNG-3156] - NullPointerException with mvn dependency:sources

 * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor

 * [MNG-3259] - Regression: Maven drops dependencies in multi-module
  build

 * [MNG-3286] - execution.inherited field is ignored

 * [MNG-3288] - Invalid systemPath allows build to continue--failing
  in later phase.

 * [MNG-3296] - mvn.bat looses error code on windows NT type
  platforms

 * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set

 * [MNG-3316] - Barfs at attribues named .*encoding

 * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
  with Novell login

 * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
  ${pom.build.testSourceDirectory} no longer recognized

 * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat

 * [MNG-3394] - Plugin versions inherited via pluginManagement
  cannot be overriden by build.plugins section of sub modules

 * [MNG-3396] - Managed versions dont affect over constrained ranges

 * [MNG-3400] - MavenProject is not extensible

 * [MNG-3405] - Checking for updates from repository logging should
  not display if WagonManager is offline

 * [MNG-3410] - Managed versions in plugins are not considered when
  using them

 * [MNG-3415] - Transfer errors cause junk metadata in the local repo

 * [MNG-3426] - regression : dependency in plugin configuration
  doesn't override plugin classpath

 * [MNG-3430] - Toolchain doesn't match

Re: [pre vote take 3] 2.0.9-RC3

2008-03-26 Thread Raphaël Piéroni

+1 the bundle worked fine to build
the archetype plugin.

Raphaël

2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
 +1 for the new process.
  not yet tested the bundle.

  Raphaël

  2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

  We fixed the regressions identified last week with the plugin tools and
reporting impl. The new 2.0.9 is staged at
  
  
  
http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.9-RC3/
  
  
  
You'll notice that this one has an RC qualifier attached to it. Since
what I've actually been staging hasn't been for an official vote, it
makes more sense to have actual deterministic numbers on them instead of
continuously rolling back and forth between .10 and .9.
  
  
  
The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the maven
release is no more regressions. To that end, what I intend to do is
let the RC sit here for a day. If no one turns up anything new (it
should be good since this is really attempt #3), then I'll email the
user list to solicit feedback. Naturally we'll probably get a slew of
can you fix xyz but the only thing that we will consider at this point
would be a regression from 2.0.8 to the current RC. If something is
identified then we should consider fixing it and re-releasing RC4. I
think that having the users more involved in testing the RCs is the only
way to really identify and eliminate regressions. If someone identifies
a regression after the fact and didn't speak up or try it, well that's
unfortunate but it'll have to wait.
  
  
  
The RC can sit with the users for 3 days. If nothing turns up, then I'll
restage with a final release tag and we can do a formal vote. Assuming
this is all successful, then I'll document a more formal Core release
procedure that we can follow going forward.
  
  
  
Here's the list of issues fixed in the latest RC:
  
  
  
Release Notes - Maven 2 - Version 2.0.9
  
  
  
  
  
** Bug
  
   * [MNG-1412] - dependency sorting in classpath
  
   * [MNG-1914] - Wrong url in error message when using a mirror
  
   * [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range
  
   * [MNG-2145] - Plugins' dependencies are not always checked
  
   * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
  
   * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty
  
   * [MNG-2339] - ${project.*} are interpreted in the wrong place
  
   * [MNG-2744] - checksum comparison should be case-insensitive
  
   * [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}
  
   * [MNG-2848] - Environment variables in profile activation not
working
  
   * [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.
  
   * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml
  
   * [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)
  
   * [MNG-2972] - Ignores version of plugin dependency specified in my
pom
  
   * [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)
  
   * [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)
  
   * [MNG-3111] - Classpath order incorrect
  
   * [MNG-3156] - NullPointerException with mvn dependency:sources
  
   * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
  
   * [MNG-3259] - Regression: Maven drops dependencies in multi-module
build
  
   * [MNG-3286] - execution.inherited field is ignored
  
   * [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.
  
   * [MNG-3296] - mvn.bat looses error code on windows NT type
platforms
  
   * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
  
   * [MNG-3316] - Barfs at attribues named .*encoding
  
   * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login
  
   * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized
  
   * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
  
   * [MNG-3394] - Plugin versions inherited via pluginManagement
cannot be overriden by build.plugins section of sub modules
  
   * [MNG-3396] - Managed versions dont affect over constrained ranges
  
   * [MNG-3400] - MavenProject is not extensible
  
   * [MNG-3405] - Checking for

Re: [pre vote take 3] 2.0.9-RC3

2008-03-26 Thread Sejal Patel

+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now (want
to make sure it works with all of our projects at work of which we have over
200 of them, several which are reactorized and have 10 or more modules to
them.).


On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni [EMAIL PROTECTED]
wrote:

 +1 the bundle worked fine to build
 the archetype plugin.

 Raphaël

 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
  +1 for the new process.
   not yet tested the bundle.
 
   Raphaël
 
   2008/3/26, Brian E. Fox [EMAIL PROTECTED]:
 
   We fixed the regressions identified last week with the plugin tools
 and
 reporting impl. The new 2.0.9 is staged at
   
   
   
   
 http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
 che-maven/2.0.9-RC3/
   
   
   
 You'll notice that this one has an RC qualifier attached to it.
 Since
 what I've actually been staging hasn't been for an official vote, it
 makes more sense to have actual deterministic numbers on them
 instead of
 continuously rolling back and forth between .10 and .9.
   
   
   
 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the
 maven
 release is no more regressions. To that end, what I intend to do
 is
 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll email the
 user list to solicit feedback. Naturally we'll probably get a slew
 of
 can you fix xyz but the only thing that we will consider at this
 point
 would be a regression from 2.0.8 to the current RC. If something is
 identified then we should consider fixing it and re-releasing RC4. I
 think that having the users more involved in testing the RCs is the
 only
 way to really identify and eliminate regressions. If someone
 identifies
 a regression after the fact and didn't speak up or try it, well
 that's
 unfortunate but it'll have to wait.
   
   
   
 The RC can sit with the users for 3 days. If nothing turns up, then
 I'll
 restage with a final release tag and we can do a formal vote.
 Assuming
 this is all successful, then I'll document a more formal Core
 release
 procedure that we can follow going forward.
   
   
   
 Here's the list of issues fixed in the latest RC:
   
   
   
 Release Notes - Maven 2 - Version 2.0.9
   
   
   
   
   
 ** Bug
   
* [MNG-1412] - dependency sorting in classpath
   
* [MNG-1914] - Wrong url in error message when using a mirror
   
* [MNG-2123] - NullPointerException when a dependency uses
 version
 range and another uses an actual version incompatible with that
 range
   
* [MNG-2145] - Plugins' dependencies are not always checked
   
* [MNG-2178] - incorrect M2_HOME guess in mvn.bat
   
* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
 when
 profiles section is missing or empty
   
* [MNG-2339] - ${project.*} are interpreted in the wrong place
   
* [MNG-2744] - checksum comparison should be case-insensitive
   
* [MNG-2809] - Can't activate a profile by checking for the
 presence
 of a file in ${user.home}
   
* [MNG-2848] - Environment variables in profile activation not
 working
   
* [MNG-2861] - NullPointerException in DefaultArtifactCollector
 for
 relocated resolvedArtifacts with different version ranges and
 available
 versions.
   
* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
 if
 there's no mojo in pom.xml
   
* [MNG-2928] - Null pointer exeception when introducing version
 range [major.minor.build-SNAPSHOT,)
   
* [MNG-2972] - Ignores version of plugin dependency specified in
 my
 pom
   
* [MNG-3086] - NullPointerException in
 ResolutionNode.getTrail(ResolutionNode.java:136)
   
* [MNG-3099] - Profiles ignored when working with non-projects
 (such
 as archetype:create)
   
* [MNG-3111] - Classpath order incorrect
   
* [MNG-3156] - NullPointerException with mvn dependency:sources
   
* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
   
* [MNG-3259] - Regression: Maven drops dependencies in
 multi-module
 build
   
* [MNG-3286] - execution.inherited field is ignored
   
* [MNG-3288] - Invalid systemPath allows build to
 continue--failing
 in later phase.
   
* [MNG-3296] - mvn.bat looses error code on windows NT type
 platforms
   
* [MNG-3310] -

RE: [pre vote take 3] 2.0.9-RC3

Sejal, thanks...that's exactly the kind of tests we'll need.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 6:47 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now (want
to make sure it works with all of our projects at work of which we have over
200 of them, several which are reactorized and have 10 or more modules to
them.).

On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni [EMAIL PROTECTED]
wrote:

 +1 the bundle worked fine to build
 the archetype plugin.

 Raphaël

 2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
  +1 for the new process.
   not yet tested the bundle.

   Raphaël

   2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

   We fixed the regressions identified last week with the plugin tools
 and
 reporting impl. The new 2.0.9 is staged at

 http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
 che-maven/2.0.9-RC3/

 You'll notice that this one has an RC qualifier attached to it.
 Since
 what I've actually been staging hasn't been for an official vote, it
 makes more sense to have actual deterministic numbers on them
 instead of
 continuously rolling back and forth between .10 and .9.

 The other significant reason it has a qualifier is that I want to
 solicit feedback from the users list without potentially getting
 multiple versions out there called 2.0.9. My new mantra for the
 maven
 release is no more regressions. To that end, what I intend to do
 is
 let the RC sit here for a day. If no one turns up anything new (it
 should be good since this is really attempt #3), then I'll email the
 user list to solicit feedback. Naturally we'll probably get a slew
 of
 can you fix xyz but the only thing that we will consider at this
 point
 would be a regression from 2.0.8 to the current RC. If something is
 identified then we should consider fixing it and re-releasing RC4. I
 think that having the users more involved in testing the RCs is the
 only
 way to really identify and eliminate regressions. If someone
 identifies
 a regression after the fact and didn't speak up or try it, well
 that's
 unfortunate but it'll have to wait.

 The RC can sit with the users for 3 days. If nothing turns up, then
 I'll
 restage with a final release tag and we can do a formal vote.
 Assuming
 this is all successful, then I'll document a more formal Core
 release
 procedure that we can follow going forward.

 Here's the list of issues fixed in the latest RC:

 Release Notes - Maven 2 - Version 2.0.9

 ** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when a dependency uses
 version
 range and another uses an actual version incompatible with that
 range

* [MNG-2145] - Plugins' dependencies are not always checked

* [MNG-2178] - incorrect M2_HOME guess in mvn.bat

* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
 when
 profiles section is missing or empty

* [MNG-2339] - ${project.*} are interpreted in the wrong place

* [MNG-2744] - checksum comparison should be case-insensitive

* [MNG-2809] - Can't activate a profile by checking for the
 presence
 of a file in ${user.home}

* [MNG-2848] - Environment variables in profile activation not
 working

* [MNG-2861] - NullPointerException in DefaultArtifactCollector
 for
 relocated resolvedArtifacts with different version ranges and
 available
 versions.

* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
 if
 there's no mojo in pom.xml

* [MNG-2928] - Null pointer exeception when introducing version
 range [major.minor.build-SNAPSHOT,)

* [MNG-2972] - Ignores version of plugin dependency specified in
 my
 pom

* [MNG-3086] - NullPointerException in
 ResolutionNode.getTrail(ResolutionNode.java:136)

* [MNG-3099] - Profiles ignored when working with non-projects
 (such
 as archetype:create)

* [MNG-3111] - Classpath order incorrect

* [MNG-3156] - NullPointerException with mvn dependency:sources

* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor

* [MNG-3259] - Regression: Maven drops dependencies in
 multi-module
 build

* [MNG-3286

RE: [pre vote take 3] 2.0.9-RC3

2008-03-26 Thread James William Dumay

Ill also build all of Atlassians products with the RC3 today and post
some results to the list

James

On Wed, 2008-03-26 at 19:55 -0400, Brian E. Fox wrote:
Sejal, thanks...that's exactly the kind of tests we'll need.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 6:47 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now (want
to make sure it works with all of our projects at work of which we have over
200 of them, several which are reactorized and have 10 or more modules to
them.).

On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni [EMAIL PROTECTED]
wrote:

+1 the bundle worked fine to build
the archetype plugin.

Raphaël

2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 for the new process.
not yet tested the bundle.

Raphaël

2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin tools
and
reporting impl. The new 2.0.9 is staged at

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
che-maven/2.0.9-RC3/

You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official vote, it
makes more sense to have actual deterministic numbers on them
instead of
continuously rolling back and forth between .10 and .9.

The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the
maven
release is no more regressions. To that end, what I intend to do
is
let the RC sit here for a day. If no one turns up anything new (it
should be good since this is really attempt #3), then I'll email the
user list to solicit feedback. Naturally we'll probably get a slew
of
can you fix xyz but the only thing that we will consider at this
point
would be a regression from 2.0.8 to the current RC. If something is
identified then we should consider fixing it and re-releasing RC4. I
think that having the users more involved in testing the RCs is the
only
way to really identify and eliminate regressions. If someone
identifies
a regression after the fact and didn't speak up or try it, well
that's
unfortunate but it'll have to wait.

The RC can sit with the users for 3 days. If nothing turns up, then
I'll
restage with a final release tag and we can do a formal vote.
Assuming
this is all successful, then I'll document a more formal Core
release
procedure that we can follow going forward.

Here's the list of issues fixed in the latest RC:

Release Notes - Maven 2 - Version 2.0.9

** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when a dependency uses
version
range and another uses an actual version incompatible with that
range

* [MNG-2145] - Plugins' dependencies are not always checked

* [MNG-2178] - incorrect M2_HOME guess in mvn.bat

* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
when
profiles section is missing or empty

* [MNG-2339] - ${project.*} are interpreted in the wrong place

* [MNG-2744] - checksum comparison should be case-insensitive

* [MNG-2809] - Can't activate a profile by checking for the
presence
of a file in ${user.home}

* [MNG-2848] - Environment variables in profile activation not
working

* [MNG-2861] - NullPointerException in DefaultArtifactCollector
for
relocated resolvedArtifacts with different version ranges and
available
versions.

* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
if
there's no mojo in pom.xml

* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)

* [MNG-2972] - Ignores version of plugin dependency specified in
my
pom

* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)

* [MNG-3099] - Profiles ignored when working with non-projects
(such
as archetype:create)

* [MNG

Re: [pre vote take 3] 2.0.9-RC3

2008-03-26 Thread Sejal Patel

Thanks but it won't be as great a test as you might think though since I
long ago locked down the plugin version numbers and stuff in a master parent
pom that is used for all projects in the company. So considering that one of
the good things about this release is the lock down of plugin version I
won't actually have a good way to test that the plugin versions included in
this release are properly tested as well.

On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:

Sejal, thanks...that's exactly the kind of tests we'll need.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 6:47 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now
(want
to make sure it works with all of our projects at work of which we have
over
200 of them, several which are reactorized and have 10 or more modules to
them.).

On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni [EMAIL PROTECTED]

wrote:

+1 the bundle worked fine to build
the archetype plugin.

Raphaël

2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 for the new process.
not yet tested the bundle.

Raphaël

2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin tools
and
reporting impl. The new 2.0.9 is staged at

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

che-maven/2.0.9-RC3/

You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official vote,
it
makes more sense to have actual deterministic numbers on them
instead of
continuously rolling back and forth between .10 and .9.

The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the
maven
release is no more regressions. To that end, what I intend to do
is
let the RC sit here for a day. If no one turns up anything new (it
should be good since this is really attempt #3), then I'll email
the
user list to solicit feedback. Naturally we'll probably get a slew
of
can you fix xyz but the only thing that we will consider at this
point
would be a regression from 2.0.8 to the current RC. If something
is
identified then we should consider fixing it and re-releasing RC4.
I
think that having the users more involved in testing the RCs is
the
only
way to really identify and eliminate regressions. If someone
identifies
a regression after the fact and didn't speak up or try it, well
that's
unfortunate but it'll have to wait.

The RC can sit with the users for 3 days. If nothing turns up,
then
I'll
restage with a final release tag and we can do a formal vote.
Assuming
this is all successful, then I'll document a more formal Core
release
procedure that we can follow going forward.

Here's the list of issues fixed in the latest RC:

Release Notes - Maven 2 - Version 2.0.9

** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when a dependency uses
version
range and another uses an actual version incompatible with that
range

* [MNG-2145] - Plugins' dependencies are not always checked

* [MNG-2178] - incorrect M2_HOME guess in mvn.bat

* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
when
profiles section is missing or empty

* [MNG-2339] - ${project.*} are interpreted in the wrong place

* [MNG-2744] - checksum comparison should be case-insensitive

* [MNG-2809] - Can't activate a profile by checking for the
presence
of a file in ${user.home}

* [MNG-2848] - Environment variables in profile activation not
working

* [MNG-2861] - NullPointerException in DefaultArtifactCollector
for
relocated resolvedArtifacts with different version ranges and
available
versions.

* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo
()
if
there's no mojo in pom.xml

* [MNG-2928] - Null

RE: [pre vote take 3] 2.0.9-RC3

That's ok, locking the plugin versions is actually something I'm not too 
worried about since in all cases we are locking to the currently released 
version, and it's a simple fix in the poms if that causes a problem. I'm 
worried about stuff like James found (MNG-3119).

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 9:56 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Thanks but it won't be as great a test as you might think though since I
long ago locked down the plugin version numbers and stuff in a master parent
pom that is used for all projects in the company. So considering that one of
the good things about this release is the lock down of plugin version I
won't actually have a good way to test that the plugin versions included in
this release are properly tested as well.

On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:

 Sejal, thanks...that's exactly the kind of tests we'll need.

 -Original Message-
 From: Sejal Patel [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 26, 2008 6:47 PM
 To: Maven Developers List
 Subject: Re: [pre vote take 3] 2.0.9-RC3

 +1 for now. Seems to work with my personal projects at home. I'll see how
 well it works on our projects at work and make sure it doesn't break
 anything that used to work with 2.0.8.

 I'll give my final answer probably in a little over 24 hours from now
 (want
 to make sure it works with all of our projects at work of which we have
 over
 200 of them, several which are reactorized and have 10 or more modules to
 them.).

 On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni [EMAIL PROTECTED]

 wrote:

  +1 the bundle worked fine to build
  the archetype plugin.

  Raphaël

  2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
   +1 for the new process.
not yet tested the bundle.

Raphaël

2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin tools
  and
  reporting impl. The new 2.0.9 is staged at

  http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

 http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

  che-maven/2.0.9-RC3/

  You'll notice that this one has an RC qualifier attached to it.
  Since
  what I've actually been staging hasn't been for an official vote,
 it
  makes more sense to have actual deterministic numbers on them
  instead of
  continuously rolling back and forth between .10 and .9.

  The other significant reason it has a qualifier is that I want to
  solicit feedback from the users list without potentially getting
  multiple versions out there called 2.0.9. My new mantra for the
  maven
  release is no more regressions. To that end, what I intend to do
  is
  let the RC sit here for a day. If no one turns up anything new (it
  should be good since this is really attempt #3), then I'll email
 the
  user list to solicit feedback. Naturally we'll probably get a slew
  of
  can you fix xyz but the only thing that we will consider at this
  point
  would be a regression from 2.0.8 to the current RC. If something
 is
  identified then we should consider fixing it and re-releasing RC4.
 I
  think that having the users more involved in testing the RCs is
 the
  only
  way to really identify and eliminate regressions. If someone
  identifies
  a regression after the fact and didn't speak up or try it, well
  that's
  unfortunate but it'll have to wait.

  The RC can sit with the users for 3 days. If nothing turns up,
 then
  I'll
  restage with a final release tag and we can do a formal vote.
  Assuming
  this is all successful, then I'll document a more formal Core
  release
  procedure that we can follow going forward.

  Here's the list of issues fixed in the latest RC:

  Release Notes - Maven 2 - Version 2.0.9

  ** Bug

 * [MNG-1412] - dependency sorting in classpath

 * [MNG-1914] - Wrong url in error message when using a mirror

 * [MNG-2123] - NullPointerException when a dependency uses
  version
  range and another uses an actual version incompatible with that
  range

 * [MNG-2145] - Plugins' dependencies are not always checked

 * [MNG-2178] - incorrect M2_HOME guess in mvn.bat

 * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
  when
  profiles section is missing or empty

 * [MNG-2339] - ${project.*} are interpreted in the wrong place

 * [MNG-2744] - checksum comparison should be case-insensitive

 * [MNG-2809] - Can't activate a profile by checking for the
  presence

Re: [pre vote take 3] 2.0.9-RC3

2008-03-26 Thread Sejal Patel

Speaking of which, I just needed to do a release and decided to try doing
the release with maven 2.0.9RC3. Seems like 3119 is not actually fixed
though as I'm running into that problem during the release. I'm attaching
the console output snipped to the 3119 report. To me this would be a
showstopper ;)

On Wed, Mar 26, 2008 at 10:20 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:

That's ok, locking the plugin versions is actually something I'm not too
worried about since in all cases we are locking to the currently released
version, and it's a simple fix in the poms if that causes a problem. I'm
worried about stuff like James found (MNG-3119).

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 9:56 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Thanks but it won't be as great a test as you might think though since I
long ago locked down the plugin version numbers and stuff in a master
parent
pom that is used for all projects in the company. So considering that one
of
the good things about this release is the lock down of plugin version I
won't actually have a good way to test that the plugin versions included
in
this release are properly tested as well.

On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:

Sejal, thanks...that's exactly the kind of tests we'll need.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2008 6:47 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

+1 for now. Seems to work with my personal projects at home. I'll see
how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now
(want
to make sure it works with all of our projects at work of which we have
over
200 of them, several which are reactorized and have 10 or more modules
to
them.).

On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni
[EMAIL PROTECTED]

wrote:

+1 the bundle worked fine to build
the archetype plugin.

Raphaël

2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 for the new process.
not yet tested the bundle.

Raphaël

2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

We fixed the regressions identified last week with the plugin
tools
and
reporting impl. The new 2.0.9 is staged at

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

che-maven/2.0.9-RC3/

You'll notice that this one has an RC qualifier attached to it.
Since
what I've actually been staging hasn't been for an official
vote,
it
makes more sense to have actual deterministic numbers on them
instead of
continuously rolling back and forth between .10 and .9.

The other significant reason it has a qualifier is that I want
to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the
maven
release is no more regressions. To that end, what I intend to
do
is
let the RC sit here for a day. If no one turns up anything new
(it
should be good since this is really attempt #3), then I'll email
the
user list to solicit feedback. Naturally we'll probably get a
slew
of
can you fix xyz but the only thing that we will consider at
this
point
would be a regression from 2.0.8 to the current RC. If something
is
identified then we should consider fixing it and re-releasing
RC4.
I
think that having the users more involved in testing the RCs is
the
only
way to really identify and eliminate regressions. If someone
identifies
a regression after the fact and didn't speak up or try it, well
that's
unfortunate but it'll have to wait.

The RC can sit with the users for 3 days. If nothing turns up,
then
I'll
restage with a final release tag and we can do a formal vote.
Assuming
this is all successful, then I'll document a more formal Core
release
procedure that we can follow going forward.

Here's the list of issues fixed in the latest RC:

Release Notes - Maven 2 - Version 2.0.9

** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when

RE: [pre vote take 3] 2.0.9-RC3

It is, we'll respin RC4 in the morning. IMO, 3119 should be permanently 
reverted (in 2.0.x) for the reasons I put in the jira.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 10:58 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Speaking of which, I just needed to do a release and decided to try doing
the release with maven 2.0.9RC3. Seems like 3119 is not actually fixed
though as I'm running into that problem during the release.  I'm attaching
the console output snipped to the 3119 report. To me this would be a
showstopper ;)

On Wed, Mar 26, 2008 at 10:20 PM, Brian E. Fox [EMAIL PROTECTED]
wrote:

 That's ok, locking the plugin versions is actually something I'm not too
 worried about since in all cases we are locking to the currently released
 version, and it's a simple fix in the poms if that causes a problem. I'm
 worried about stuff like James found (MNG-3119).

 -Original Message-
 From: Sejal Patel [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, March 26, 2008 9:56 PM
 To: Maven Developers List
 Subject: Re: [pre vote take 3] 2.0.9-RC3

 Thanks but it won't be as great a test as you might think though since I
 long ago locked down the plugin version numbers and stuff in a master
 parent
 pom that is used for all projects in the company. So considering that one
 of
 the good things about this release is the lock down of plugin version I
 won't actually have a good way to test that the plugin versions included
 in
 this release are properly tested as well.

 On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox [EMAIL PROTECTED]
 wrote:

  Sejal, thanks...that's exactly the kind of tests we'll need.

  -Original Message-
  From: Sejal Patel [mailto:[EMAIL PROTECTED]
  Sent: Wednesday, March 26, 2008 6:47 PM
  To: Maven Developers List
  Subject: Re: [pre vote take 3] 2.0.9-RC3

  +1 for now. Seems to work with my personal projects at home. I'll see
 how
  well it works on our projects at work and make sure it doesn't break
  anything that used to work with 2.0.8.

  I'll give my final answer probably in a little over 24 hours from now
  (want
  to make sure it works with all of our projects at work of which we have
  over
  200 of them, several which are reactorized and have 10 or more modules
 to
  them.).

  On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni 
 [EMAIL PROTECTED]

  wrote:

   +1 the bundle worked fine to build
   the archetype plugin.

   Raphaël

   2008/3/26, Raphaël Piéroni [EMAIL PROTECTED]:
+1 for the new process.
 not yet tested the bundle.

 Raphaël

 2008/3/26, Brian E. Fox [EMAIL PROTECTED]:

 We fixed the regressions identified last week with the plugin
 tools
   and
   reporting impl. The new 2.0.9 is staged at

 http://people.apache.org/~brianf/staging-repository/org/apache/maven/apahttp://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

 http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

 http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa

   che-maven/2.0.9-RC3/

   You'll notice that this one has an RC qualifier attached to it.
   Since
   what I've actually been staging hasn't been for an official
 vote,
  it
   makes more sense to have actual deterministic numbers on them
   instead of
   continuously rolling back and forth between .10 and .9.

   The other significant reason it has a qualifier is that I want
 to
   solicit feedback from the users list without potentially getting
   multiple versions out there called 2.0.9. My new mantra for the
   maven
   release is no more regressions. To that end, what I intend to
 do
   is
   let the RC sit here for a day. If no one turns up anything new
 (it
   should be good since this is really attempt #3), then I'll email
  the
   user list to solicit feedback. Naturally we'll probably get a
 slew
   of
   can you fix xyz but the only thing that we will consider at
 this
   point
   would be a regression from 2.0.8 to the current RC. If something
  is
   identified then we should consider fixing it and re-releasing
 RC4.
  I
   think that having the users more involved in testing the RCs is
  the
   only
   way to really identify and eliminate regressions. If someone
   identifies
   a regression after the fact and didn't speak up or try it, well
   that's
   unfortunate but it'll have to wait.

   The RC can sit with the users for 3 days. If nothing turns up,
  then
   I'll
   restage with a final release tag and we can do a formal vote.
   Assuming
   this is all successful, then I'll document a more formal Core
   release
   procedure that we can follow going forward.

   Here's the list of issues fixed in the latest RC

RE: [pre vote take 3] 2.0.9-RC3