On 16 Mar 07, at 2:46 PM 16 Mar 07, 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, and even in the jira issue Brett says that it was
done on purpose.
It's not clear because it's bites people all the time because it's
not intuitive at all.
http://maven.apache.org/guides/introduction/introduction-to-
dependency-mechanism.html
You think anyone reads that first? It's simply not what's expected.
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
No they won't. If you have overridden a dependency in a child that
definition wins. Again as expected. As you expect if you override the
version. What people can start doing to improve their situation is
remove that version, manage it from depMan and still get the correct
version, the one they selected, put into the graph. This behavior
would not change how child project define dependencies i.e. the
definition in the child will win. The patch allows real management
from the depMan of the versions used and that's really what it boils
down to.
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 not a feature change, it's a fundamental defect.
Jason.
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]
--
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]
