You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2008/03/27 18:06:38 UTC
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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>> 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 Toolchain extensions
>>>
>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>
>>> * [MNG-3439] - incorrect child dependency selected when
>>> parent is
>>> not selected
>>>
>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>> updated
>>> from the deployment repository
>>>
>>> * [MNG-3460] -
>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>> fails if you use a different local repo
>>>
>>> * [MNG-3464] - maven-toolchains missing from final binary.. need
>> to
>>> update the assembly
>>>
>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
>>> ONLY) is broken
>>>
>>>
>>>
>>> ** Improvement
>>>
>>> * [MNG-428] - Japanese message resource
>>>
>>> * [MNG-2881] - Improve logging when downloading snapshots in
>> offline
>>> mode
>>>
>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>> allowed.
>>>
>>> * [MNG-3279] - Support Exception Chaining for
>>> MojoFailureException
>>>
>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>> equals
>>> and hashCode methods
>>>
>>> * [MNG-3331] - Normalize paths to sub modules
>>>
>>> * [MNG-3388] - DefaultPluginManager needs to catch LinkageError
>>>
>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>
>>> * [MNG-3442] - Add explicit resource bundle for English
>>>
>>> * [MNG-3461] - Mirrors should not apply to file:// repositories
>>>
>>> * [MNG-3467] - PatternSet needs a toString() method to properly
>>> print in debug mode
>>>
>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>> print
>>> in debug mode
>>>
>>> * [MNG-3469] - Resource needs a toString() method to properly
>> print
>>> in debug mode
>>>
>>>
>>>
>>> ** New Feature
>>>
>>> * [MNG-2664] - Add native support for webdav
>>>
>>>
>>>
>>> ** Task
>>>
>>> * [MNG-2883] - Make sure that the network isn't used for
>>> snapshots
>>> in offline mode when legacy repositories are used
>>>
>>>
>>>
>>>
>>>
>>> ** Wish
>>>
>>> * [MNG-1491] - Reactor should print out a message if it
>>> detects a
>>> collision of artifact ids
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by Jason van Zyl <ja...@maven.org>.
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:jdcasey@commonjava.org]
>> 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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>>>>> 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 Toolchain extensions
>>>>>>
>>>>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>>>>
>>>>>> * [MNG-3439] - incorrect child dependency selected when
>>>>>> parent is
>>>>>> not selected
>>>>>>
>>>>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>>>>> updated
>>>>>> from the deployment repository
>>>>>>
>>>>>> * [MNG-3460] -
>>>>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>>>>> fails if you use a different local repo
>>>>>>
>>>>>> * [MNG-3464] - maven-toolchains missing from final binary..
>>>>>> need
>>>>> to
>>>>>> update the assembly
>>>>>>
>>>>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report
>>>>>> (2.4
>>>>>> ONLY) is broken
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** Improvement
>>>>>>
>>>>>> * [MNG-428] - Japanese message resource
>>>>>>
>>>>>> * [MNG-2881] - Improve logging when downloading snapshots in
>>>>> offline
>>>>>> mode
>>>>>>
>>>>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>>>>> allowed.
>>>>>>
>>>>>> * [MNG-3279] - Support Exception Chaining for
>>>>>> MojoFailureException
>>>>>>
>>>>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>>>>> equals
>>>>>> and hashCode methods
>>>>>>
>>>>>> * [MNG-3331] - Normalize paths to sub modules
>>>>>>
>>>>>> * [MNG-3388] - DefaultPluginManager needs to catch
>>>>>> LinkageError
>>>>>>
>>>>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>>>>
>>>>>> * [MNG-3442] - Add explicit resource bundle for English
>>>>>>
>>>>>> * [MNG-3461] - Mirrors should not apply to file://
>>>>>> repositories
>>>>>>
>>>>>> * [MNG-3467] - PatternSet needs a toString() method to
>>>>>> properly
>>>>>> print in debug mode
>>>>>>
>>>>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>>>>> print
>>>>>> in debug mode
>>>>>>
>>>>>> * [MNG-3469] - Resource needs a toString() method to properly
>>>>> print
>>>>>> in debug mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** New Feature
>>>>>>
>>>>>> * [MNG-2664] - Add native support for webdav
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** Task
>>>>>>
>>>>>> * [MNG-2883] - Make sure that the network isn't used for
>>>>>> snapshots
>>>>>> in offline mode when legacy repositories are used
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** Wish
>>>>>>
>>>>>> * [MNG-1491] - Reactor should print out a message if it
>>>>>> detects a
>>>>>> collision of artifact ids
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---
>>>> John Casey
>>>> Committer and PMC Member, Apache Maven
>>>> mail: jdcasey at commonjava dot org
>>>> blog: http://www.ejlife.net/blogs/john
>>>> rss: http://feeds.feedburner.com/ejlife/john
>>>>
>>>>
>>>
>>> ---
>>> John Casey
>>> Committer and PMC Member, Apache Maven
>>> mail: jdcasey at commonjava dot org
>>> blog: http://www.ejlife.net/blogs/john
>>> rss: http://feeds.feedburner.com/ejlife/john
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> John Casey
>> Committer and PMC Member, Apache Maven
>> mail: jdcasey at commonjava dot org
>> blog: http://www.ejlife.net/blogs/john
>> rss: http://feeds.feedburner.com/ejlife/john
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Our achievements speak for themselves. What we have to keep track
of are our failures, discouragements and doubts. We tend to forget
the past difficulties, the many false starts, and the painful
groping. We see our past achievements as the end result of a
clean forward thrust, and our present difficulties as
signs of decline and decay.
-- Eric Hoffer, Reflections on the Human Condition
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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: paulus.benedictus@gmail.com [mailto:paulus.benedictus@gmail.com]
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 <br...@reply.infinity.nu>
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by Brett Porter <br...@apache.org>.
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
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by Paul Benedict <pb...@apache.org>.
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 <br...@reply.infinity.nu>
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by Brett Porter <br...@apache.org>.
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:jdcasey@commonjava.org]
>> 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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>>>>> 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 Toolchain extensions
>>>>>>
>>>>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>>>>
>>>>>> * [MNG-3439] - incorrect child dependency selected when
>>>>>> parent is
>>>>>> not selected
>>>>>>
>>>>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>>>>> updated
>>>>>> from the deployment repository
>>>>>>
>>>>>> * [MNG-3460] -
>>>>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>>>>> fails if you use a different local repo
>>>>>>
>>>>>> * [MNG-3464] - maven-toolchains missing from final binary..
>>>>>> need
>>>>> to
>>>>>> update the assembly
>>>>>>
>>>>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report
>>>>>> (2.4
>>>>>> ONLY) is broken
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** Improvement
>>>>>>
>>>>>> * [MNG-428] - Japanese message resource
>>>>>>
>>>>>> * [MNG-2881] - Improve logging when downloading snapshots in
>>>>> offline
>>>>>> mode
>>>>>>
>>>>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>>>>> allowed.
>>>>>>
>>>>>> * [MNG-3279] - Support Exception Chaining for
>>>>>> MojoFailureException
>>>>>>
>>>>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>>>>> equals
>>>>>> and hashCode methods
>>>>>>
>>>>>> * [MNG-3331] - Normalize paths to sub modules
>>>>>>
>>>>>> * [MNG-3388] - DefaultPluginManager needs to catch
>>>>>> LinkageError
>>>>>>
>>>>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>>>>
>>>>>> * [MNG-3442] - Add explicit resource bundle for English
>>>>>>
>>>>>> * [MNG-3461] - Mirrors should not apply to file://
>>>>>> repositories
>>>>>>
>>>>>> * [MNG-3467] - PatternSet needs a toString() method to
>>>>>> properly
>>>>>> print in debug mode
>>>>>>
>>>>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>>>>> print
>>>>>> in debug mode
>>>>>>
>>>>>> * [MNG-3469] - Resource needs a toString() method to properly
>>>>> print
>>>>>> in debug mode
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** New Feature
>>>>>>
>>>>>> * [MNG-2664] - Add native support for webdav
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** Task
>>>>>>
>>>>>> * [MNG-2883] - Make sure that the network isn't used for
>>>>>> snapshots
>>>>>> in offline mode when legacy repositories are used
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ** Wish
>>>>>>
>>>>>> * [MNG-1491] - Reactor should print out a message if it
>>>>>> detects a
>>>>>> collision of artifact ids
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---
>>>> John Casey
>>>> Committer and PMC Member, Apache Maven
>>>> mail: jdcasey at commonjava dot org
>>>> blog: http://www.ejlife.net/blogs/john
>>>> rss: http://feeds.feedburner.com/ejlife/john
>>>>
>>>>
>>>
>>> ---
>>> John Casey
>>> Committer and PMC Member, Apache Maven
>>> mail: jdcasey at commonjava dot org
>>> blog: http://www.ejlife.net/blogs/john
>>> rss: http://feeds.feedburner.com/ejlife/john
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> John Casey
>> Committer and PMC Member, Apache Maven
>> mail: jdcasey at commonjava dot org
>> blog: http://www.ejlife.net/blogs/john
>> rss: http://feeds.feedburner.com/ejlife/john
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by John Casey <jd...@commonjava.org>.
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:jdcasey@commonjava.org]
> 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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>>>> 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 Toolchain extensions
>>>>>
>>>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>>>
>>>>> * [MNG-3439] - incorrect child dependency selected when
>>>>> parent is
>>>>> not selected
>>>>>
>>>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>>>> updated
>>>>> from the deployment repository
>>>>>
>>>>> * [MNG-3460] -
>>>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>>>> fails if you use a different local repo
>>>>>
>>>>> * [MNG-3464] - maven-toolchains missing from final binary..
>>>>> need
>>>> to
>>>>> update the assembly
>>>>>
>>>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report
>>>>> (2.4
>>>>> ONLY) is broken
>>>>>
>>>>>
>>>>>
>>>>> ** Improvement
>>>>>
>>>>> * [MNG-428] - Japanese message resource
>>>>>
>>>>> * [MNG-2881] - Improve logging when downloading snapshots in
>>>> offline
>>>>> mode
>>>>>
>>>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>>>> allowed.
>>>>>
>>>>> * [MNG-3279] - Support Exception Chaining for
>>>>> MojoFailureException
>>>>>
>>>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>>>> equals
>>>>> and hashCode methods
>>>>>
>>>>> * [MNG-3331] - Normalize paths to sub modules
>>>>>
>>>>> * [MNG-3388] - DefaultPluginManager needs to catch
>>>>> LinkageError
>>>>>
>>>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>>>
>>>>> * [MNG-3442] - Add explicit resource bundle for English
>>>>>
>>>>> * [MNG-3461] - Mirrors should not apply to file://
>>>>> repositories
>>>>>
>>>>> * [MNG-3467] - PatternSet needs a toString() method to
>>>>> properly
>>>>> print in debug mode
>>>>>
>>>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>>>> print
>>>>> in debug mode
>>>>>
>>>>> * [MNG-3469] - Resource needs a toString() method to properly
>>>> print
>>>>> in debug mode
>>>>>
>>>>>
>>>>>
>>>>> ** New Feature
>>>>>
>>>>> * [MNG-2664] - Add native support for webdav
>>>>>
>>>>>
>>>>>
>>>>> ** Task
>>>>>
>>>>> * [MNG-2883] - Make sure that the network isn't used for
>>>>> snapshots
>>>>> in offline mode when legacy repositories are used
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ** Wish
>>>>>
>>>>> * [MNG-1491] - Reactor should print out a message if it
>>>>> detects a
>>>>> collision of artifact ids
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> -
>
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---
>>> John Casey
>>> Committer and PMC Member, Apache Maven
>>> mail: jdcasey at commonjava dot org
>>> blog: http://www.ejlife.net/blogs/john
>>> rss: http://feeds.feedburner.com/ejlife/john
>>>
>>>
>>
>> ---
>> John Casey
>> Committer and PMC Member, Apache Maven
>> mail: jdcasey at commonjava dot org
>> blog: http://www.ejlife.net/blogs/john
>> rss: http://feeds.feedburner.com/ejlife/john
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:jdcasey@commonjava.org]
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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>>> 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 Toolchain extensions
>>>>
>>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>>
>>>> * [MNG-3439] - incorrect child dependency selected when
>>>> parent is
>>>> not selected
>>>>
>>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>>> updated
>>>> from the deployment repository
>>>>
>>>> * [MNG-3460] -
>>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>>> fails if you use a different local repo
>>>>
>>>> * [MNG-3464] - maven-toolchains missing from final binary..
>>>> need
>>> to
>>>> update the assembly
>>>>
>>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report
>>>> (2.4
>>>> ONLY) is broken
>>>>
>>>>
>>>>
>>>> ** Improvement
>>>>
>>>> * [MNG-428] - Japanese message resource
>>>>
>>>> * [MNG-2881] - Improve logging when downloading snapshots in
>>> offline
>>>> mode
>>>>
>>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>>> allowed.
>>>>
>>>> * [MNG-3279] - Support Exception Chaining for
>>>> MojoFailureException
>>>>
>>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>>> equals
>>>> and hashCode methods
>>>>
>>>> * [MNG-3331] - Normalize paths to sub modules
>>>>
>>>> * [MNG-3388] - DefaultPluginManager needs to catch LinkageError
>>>>
>>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>>
>>>> * [MNG-3442] - Add explicit resource bundle for English
>>>>
>>>> * [MNG-3461] - Mirrors should not apply to file:// repositories
>>>>
>>>> * [MNG-3467] - PatternSet needs a toString() method to properly
>>>> print in debug mode
>>>>
>>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>>> print
>>>> in debug mode
>>>>
>>>> * [MNG-3469] - Resource needs a toString() method to properly
>>> print
>>>> in debug mode
>>>>
>>>>
>>>>
>>>> ** New Feature
>>>>
>>>> * [MNG-2664] - Add native support for webdav
>>>>
>>>>
>>>>
>>>> ** Task
>>>>
>>>> * [MNG-2883] - Make sure that the network isn't used for
>>>> snapshots
>>>> in offline mode when legacy repositories are used
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ** Wish
>>>>
>>>> * [MNG-1491] - Reactor should print out a message if it
>>>> detects a
>>>> collision of artifact ids
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> John Casey
>> Committer and PMC Member, Apache Maven
>> mail: jdcasey at commonjava dot org
>> blog: http://www.ejlife.net/blogs/john
>> rss: http://feeds.feedburner.com/ejlife/john
>>
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by John Casey <jd...@commonjava.org>.
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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>>> 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 Toolchain extensions
>>>>
>>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>>
>>>> * [MNG-3439] - incorrect child dependency selected when
>>>> parent is
>>>> not selected
>>>>
>>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>>> updated
>>>> from the deployment repository
>>>>
>>>> * [MNG-3460] -
>>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>>> fails if you use a different local repo
>>>>
>>>> * [MNG-3464] - maven-toolchains missing from final binary..
>>>> need
>>> to
>>>> update the assembly
>>>>
>>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report
>>>> (2.4
>>>> ONLY) is broken
>>>>
>>>>
>>>>
>>>> ** Improvement
>>>>
>>>> * [MNG-428] - Japanese message resource
>>>>
>>>> * [MNG-2881] - Improve logging when downloading snapshots in
>>> offline
>>>> mode
>>>>
>>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>>> allowed.
>>>>
>>>> * [MNG-3279] - Support Exception Chaining for
>>>> MojoFailureException
>>>>
>>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>>> equals
>>>> and hashCode methods
>>>>
>>>> * [MNG-3331] - Normalize paths to sub modules
>>>>
>>>> * [MNG-3388] - DefaultPluginManager needs to catch LinkageError
>>>>
>>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>>
>>>> * [MNG-3442] - Add explicit resource bundle for English
>>>>
>>>> * [MNG-3461] - Mirrors should not apply to file:// repositories
>>>>
>>>> * [MNG-3467] - PatternSet needs a toString() method to properly
>>>> print in debug mode
>>>>
>>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>>> print
>>>> in debug mode
>>>>
>>>> * [MNG-3469] - Resource needs a toString() method to properly
>>> print
>>>> in debug mode
>>>>
>>>>
>>>>
>>>> ** New Feature
>>>>
>>>> * [MNG-2664] - Add native support for webdav
>>>>
>>>>
>>>>
>>>> ** Task
>>>>
>>>> * [MNG-2883] - Make sure that the network isn't used for
>>>> snapshots
>>>> in offline mode when legacy repositories are used
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ** Wish
>>>>
>>>> * [MNG-1491] - Reactor should print out a message if it
>>>> detects a
>>>> collision of artifact ids
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---
>> John Casey
>> Committer and PMC Member, Apache Maven
>> mail: jdcasey at commonjava dot org
>> blog: http://www.ejlife.net/blogs/john
>> rss: http://feeds.feedburner.com/ejlife/john
>>
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
RE: CLI Properties vs. Model Properties (Was Re: [pre vote take 3] 2.0.9-RC3)
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:jdcasey@commonjava.org]
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: oliver.lamy@gmail.com [mailto:oliver.lamy@gmail.com] 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 <br...@reply.infinity.nu>:
>>> 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 Toolchain extensions
>>>
>>> * [MNG-3431] - Pom Extensions not supported for Toolchains
>>>
>>> * [MNG-3439] - incorrect child dependency selected when
>>> parent is
>>> not selected
>>>
>>> * [MNG-3441] - Maven should always retrieve metadata to be
>>> updated
>>> from the deployment repository
>>>
>>> * [MNG-3460] -
>>> org.apache.maven.profiles.DefaultProfileManagerTest
>>> fails if you use a different local repo
>>>
>>> * [MNG-3464] - maven-toolchains missing from final binary.. need
>> to
>>> update the assembly
>>>
>>> * [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
>>> ONLY) is broken
>>>
>>>
>>>
>>> ** Improvement
>>>
>>> * [MNG-428] - Japanese message resource
>>>
>>> * [MNG-2881] - Improve logging when downloading snapshots in
>> offline
>>> mode
>>>
>>> * [MNG-3119] - Duplicate attached artifacts should not be
>>> allowed.
>>>
>>> * [MNG-3279] - Support Exception Chaining for
>>> MojoFailureException
>>>
>>> * [MNG-3318] - ActiveProjectArtifact should have appropriate
>> equals
>>> and hashCode methods
>>>
>>> * [MNG-3331] - Normalize paths to sub modules
>>>
>>> * [MNG-3388] - DefaultPluginManager needs to catch LinkageError
>>>
>>> * [MNG-3395] - Default core plugin versions in the superpom.
>>>
>>> * [MNG-3442] - Add explicit resource bundle for English
>>>
>>> * [MNG-3461] - Mirrors should not apply to file:// repositories
>>>
>>> * [MNG-3467] - PatternSet needs a toString() method to properly
>>> print in debug mode
>>>
>>> * [MNG-3468] - FileSet needs a toString() method to properly
>>> print
>>> in debug mode
>>>
>>> * [MNG-3469] - Resource needs a toString() method to properly
>> print
>>> in debug mode
>>>
>>>
>>>
>>> ** New Feature
>>>
>>> * [MNG-2664] - Add native support for webdav
>>>
>>>
>>>
>>> ** Task
>>>
>>> * [MNG-2883] - Make sure that the network isn't used for
>>> snapshots
>>> in offline mode when legacy repositories are used
>>>
>>>
>>>
>>>
>>>
>>> ** Wish
>>>
>>> * [MNG-1491] - Reactor should print out a message if it
>>> detects a
>>> collision of artifact ids
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
> rss: http://feeds.feedburner.com/ejlife/john
>
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org