Carlos Sanchez wrote:
it's not unpredictable at all, it is pretty clear that to force a
version in a project you need to add it in your pom and
dependencyManagement doesn't affect transitive dependencies, it's in
the documentation,
Where?
and even in the jira issue Brett says that it was
done on purpose.
http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Nothing about this mentioned there..
now poms in the repo that have dependencyManagement sections will
start to change the behavior of current builds and people with 2.0.5
will get very different results than people with 2.0.6 which i don't
think it's acceptable for 2.0.x
How? a pom in the repo with a depMgt section will only affect it's own
dependencies, not the project depending on that pom in that repo.
If it didn't already specify a depMgt it will be unpredictable, and if it does,
then this change has no effect, since to fix a transitive dep's version
the dependency has to be specified in that pom too; so it'll contain both
a depMgt _and_ a dependency.
I'm not against the fix, and I wouldn't really care if this is shipped
next week as 2.1 and current 2.1 is moved to 2.2, or even better get
2.1 alpha now with this fix (+100!)
It's a bugfix, I don't see why this can't be applied to the version that
contains
the bug, but this bug has to be supported throughout the 2.0.x line.
So we've established that this bugfix is something we want and it should go in
2.1, 2.2 etc. So why try to support the unpredictable behaviour in 2.0.x?
I simply cannot understand how we can make 2.0.6 or newer behave in the same
unpredictable way (the case where the dependency is NOT specified to override
the depMgt section). That's just unsupportable.
-- Kenney
On 3/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 16 Mar 07, at 1:35 PM 16 Mar 07, Carlos Sanchez wrote:
> I agree with Brett, this is a 2.1 change, not a 2.0.x
>
Do you fully understand what the current behavior is and what this
patch fixes? You are essentially condemning users to complete
unpredictability. I really think that a build should be staged and
explain to users what the change is and let people build with it. If
we don't get enough feedback or there is a consensus that they think
it's not good then we don't put it in. But we already have many users
who are suffering and asking for this to be the default behavior.
Jason.
> Now as Jochen says, nothing prevents pushing stuff from 2.1 to 2.2 and
> get an earlier 2.1, i though we were going to do it anyway.
>
>
> On 3/16/07, Jochen Wiedmann <[EMAIL PROTECTED]> wrote:
>> On 3/16/07, Brett Porter <[EMAIL PROTECTED]> wrote:
>>
>> > Our users must be able to trust point releases are safe upgrades.
>> > Let's start moving on putting out 2.1 milestone releases instead.
>>
>> Agreed. On the other hand, most others seem to consider this
>> change important.
>>
>> So, why not simply renaming 2.0.6 to 2.1 and 2.1 to 2.2? Should
>> satisfy all.
>>
>> Jochen
>>
>> --
>> Emacs 22 will support MacOS and CygWin. It is not yet decided,
>> whether
>> these will be used to run Emacs or the other way round.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
