[vote] MNG-1577 as the default behavior

[Carlos Sanchez-4]

On 3/16/07, Kenney Westerhof <kenney@...> wrote:
> You're only describing the case where you override the version by specifying
> a transitive dep directly. If you don't, then it's unpredictable.
> If I say in my pom 'i want junit 4 for my modules' and some transitive dep has junit 3
> my build can break because i get the wrong dep.
>

maybe we understand different things for unpredictable. If you know
that dependencyManagement only affects your children it's completely
predictable.

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

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

[Brian E Fox]

>i don't follow you here, the problem is when 2.0.5 builds get some
version
>"by default" (they don't override it). Those builds would get another
version in 2.0.6

I think it simply boils down to what Patrick  wrote:

"For existing projects in which the workaround was not used, then I
would question two things:

- Does the project work as expected?
- Do they really care what version of D gets pulled in?

If they are not using the work around, it seems to me that the answer to
at least one of these would have to be 'No'.  And in this case, it
doesn't seem like altering the behavior matters much anyway."

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

[Carlos Sanchez-4]

On 3/16/07, Brian E. Fox <brianf@...> wrote:

>
>
> >i don't follow you here, the problem is when 2.0.5 builds get some
> version
> >"by default" (they don't override it). Those builds would get another
> version in 2.0.6
>
> I think it simply boils down to what Patrick  wrote:
>
> "For existing projects in which the workaround was not used, then I
> would question two things:
>
> - Does the project work as expected?
> - Do they really care what version of D gets pulled in?
>
> If they are not using the work around, it seems to me that the answer to
> at least one of these would have to be 'No'.  And in this case, it
> doesn't seem like altering the behavior matters much anyway."

one of the points of maven is to worry less about the build, so if i
get the dependency i need why should i care to add it explicitly? they
may not care about the version until they upgrade to 2.0.6 and it
breaks

it's not a matter on how it should work, I agree that the patch is
good, but not for changing behavior between 2.0.x releases.

Just think how are you going to handle questions from users, I feel
more natural ask for "are you using 2.0 or 2.1" than "2.0.5 or 2.0.6
or ..."


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


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                             -- The Princess Bride

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

[mperham]

The key question to me is: are existing 2.0.5 builds going to be
better or worse after this upgrade?  I would prefer to see less
speculation and more bits.  Put out a Maven 2.0.6 snapshot that people
can try with their project and get reports from the people in this
thread.  If no one has problems, this discussion becomes a lot
shorter.  If they do have problems, at least we have specific examples
to discuss.

mike

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

[John Casey]

That sounds like a great idea, Mike. It's all academic until we put
something out there.

-j

On 3/16/07, Mike Perham <mperham@...> wrote:

>
> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade?  I would prefer to see less
> speculation and more bits.  Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread.  If no one has problems, this discussion becomes a lot
> shorter.  If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Fabrizio Giustina-4]

A big +1 for making it a default

I am also +1 on adding this to 2.0.6: for me this would just mean
removing tons of unneeded/workaround dependency from tons of poms. I
agree that, although consistent for some time, this behavior
introduces so much problems that should be considered a bug and not a
behavior.

Since anyway this is a important change and so many people are worried
about it, I would just propose to label 2.0.6 as 2.1 (trunk will
become 2.2). That should the reason for version numbers, right? We
shouldn't wait for trunk to be ready to name a release 2.1 and if we
introduce a change we should label it appropriately...

fabrizio



On 3/16/07, Jason van Zyl <jason@...> wrote:

> Hi,
>
> After working with it a little this week I would like to propose to
> make MNG-1577 behavior introduced the default. Builds are completely
> and totally unpredictable without this behavior. The behavior in
> 2.0.5 is fundamentally broken. To are totally prey to any dependency
> introduced by a dependency which makes no sense and completely
> counter intuitive. I stabilized a massive build this week simply by
> using the behavior present in the 2.0.x branch. I don't think we're
> doing anyone any favors leaving the old behavior in. After watching a
> disaster be recovered by using this new behavior I feel that the
> patch should go in as is and become the default behavior. This puts
> the user in control which is the way it should be.
>
> I propose we make this the default behavior. Can anyone think of a
> case where this degree of control would break an existing build?
>
> This patch saved my bacon this week, I think this behavior makes a
> world of difference to users.
>
> Jason.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Jason van Zyl-2]

On 16 Mar 07, at 4:02 PM 16 Mar 07, Carlos Sanchez wrote:

> On 3/16/07, Brian E. Fox <brianf@...> wrote:
>>
>>
>> >i don't follow you here, the problem is when 2.0.5 builds get some
>> version
>> >"by default" (they don't override it). Those builds would get  
>> another
>> version in 2.0.6
>>
>> I think it simply boils down to what Patrick  wrote:
>>
>> "For existing projects in which the workaround was not used, then I
>> would question two things:
>>
>> - Does the project work as expected?
>> - Do they really care what version of D gets pulled in?
>>
>> If they are not using the work around, it seems to me that the  
>> answer to
>> at least one of these would have to be 'No'.  And in this case, it
>> doesn't seem like altering the behavior matters much anyway."
>
>
> one of the points of maven is to worry less about the build, so if i
> get the dependency i need why should i care to add it explicitly?

For any numbers of reasons that you might know of for selecting one  
version over another. A binary incompatibility, a feature you want,  
because you like odd numbered releases, it doesn't matter what the  
reason is, the point is that it is done in practice. When someone  
selects that version, it should be honored in the scope of the  
project you are building.

> they
> may not care about the version until they upgrade to 2.0.6 and it
> breaks

It will not break if you have explicitly set a version in a child  
module. Look at the code.

>
> it's not a matter on how it should work, I agree that the patch is
> good, but not for changing behavior between 2.0.x releases.

We will do as Mike suggested and build something for people to use. I  
see no effective change in behavior except in the case where someone  
is relying on something they expect but are getting something  
different. Without the patch if there is no parity between building  
on a leaf and from the top-level. Depending on where you build you  
might get different versions. That's fundamentally wrong and a total  
crap shoot. If that was explained to users I guarantee they wouldn't  
take the crap shoot.

>
> Just think how are you going to handle questions from users, I feel
> more natural ask for "are you using 2.0 or 2.1" than "2.0.5 or 2.0.6
> or ..."

That's not the question to be asking. The question posed to a user  
would be "looking at the depMan section, where the version of X is  
set to 1.0, what version would you expect to be used in a child  
module?" Invariably the answer will be "the one I selected", not,  
"the one maven thinks it should give me."

If we applied this patch a year ago when at 2.0.3, would we have  
jumped to 2.1? No. When we have fixed the behavior of scopes or  
anything else regarding dependency resolution which certainly could  
break peoples' builds did we jump to a new version range? No. People  
have probably been bitten in those cases because 1) We don't have a  
spec, and 2) Hardly anything is documented. This change will help a  
lot more people then it may harm, and the people it dings will have  
revealed for them inconsistencies that would probably do them more harm.

Jason.

>
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>                             -- The Princess Bride
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Kenney Westerhof-3]

Fabrizio Giustina wrote:

> A big +1 for making it a default
>
> I am also +1 on adding this to 2.0.6: for me this would just mean
> removing tons of unneeded/workaround dependency from tons of poms. I
> agree that, although consistent for some time, this behavior
> introduces so much problems that should be considered a bug and not a
> behavior.
>
> Since anyway this is a important change and so many people are worried
> about it, I would just propose to label 2.0.6 as 2.1 (trunk will
> become 2.2). That should the reason for version numbers, right? We
> shouldn't wait for trunk to be ready to name a release 2.1 and if we
> introduce a change we should label it appropriately...

-1, because with this next release as 2.1, the 2.0 branch will no longer
be supported. What you're saying is basically 'we name the next release of
'2.0.x' '2.1''. What's the point of that? That's just the type of thing
that happens in commercial environments to satisfy PR and management.
So dropping 2.0.x and making 2.0.6 the next 2.1 is not an option.

Second option would be to keep 2.0.x in place and make 2.0.5 the starting
point of 2.1, with this patch in place. That would mean we still
have to support 2.0.x, and 2.1, which is no different from 2.0.x
except for MNG-1577, and the 2.1, what is now 2.1.
That's not an option either, since this little issue, although higly debated,
does not warrant a minor version update. yes, it changes behaviour. But fixing
a bug also changes behaviour.

Third option: keep 2.0.x buggy and only apply to 2.1.

Fourth option: apply to both 2.0.x and 2.1.

My vote goes to 4, after ofcourse we've tested a release candidate of 2.0.6.

-- Kenney

>
> fabrizio
>
>
>
> On 3/16/07, Jason van Zyl <jason@...> wrote:
>> Hi,
>>
>> After working with it a little this week I would like to propose to
>> make MNG-1577 behavior introduced the default. Builds are completely
>> and totally unpredictable without this behavior. The behavior in
>> 2.0.5 is fundamentally broken. To are totally prey to any dependency
>> introduced by a dependency which makes no sense and completely
>> counter intuitive. I stabilized a massive build this week simply by
>> using the behavior present in the 2.0.x branch. I don't think we're
>> doing anyone any favors leaving the old behavior in. After watching a
>> disaster be recovered by using this new behavior I feel that the
>> patch should go in as is and become the default behavior. This puts
>> the user in control which is the way it should be.
>>
>> I propose we make this the default behavior. Can anyone think of a
>> case where this degree of control would break an existing build?
>>
>> This patch saved my bacon this week, I think this behavior makes a
>> world of difference to users.
>>
>> Jason.
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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

[brettporter]

Mike,

Good plan. This is exactly what I was getting at - but I thought we  
could already do this from the branch that the feature was  
implemented on? That's what I was intending to use.

I'm obviously having trouble grokking the actual implications of this  
- I was getting the clear impression this was going to break builds,  
but it seems that may not be the case from the ensuing discussion. So  
all I really want to do is play with it and see for myself at this  
point. I have some time later today/tomorrow.

- Brett

On 17/03/2007, at 7:35 AM, Mike Perham wrote:

> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade?  I would prefer to see less
> speculation and more bits.  Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread.  If no one has problems, this discussion becomes a lot
> shorter.  If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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

[Ralph Goers]

Jason van Zyl wrote:
>
> I will work with Patrick to put the old and new in 2.0.x. If it really
> comes down to turning it off by default, which would be an immense
> shame, then so be it and people will just have to turn it on. We'll
> just devise a very easy way to turn it on like a property in the
> top-level POM. We can't jump from 2.0.6 to a 2.1 for this.
>
> Jason.
>
Jason,

I would take the override option off the table.

When I wrote the patch for MNG-1577 I added an override element to the
dependencyManagement element in the pom so backward compatibility could
be preserved. However, I realized later that that change itself would
cause problems. This is because adding anything to the pom really
requires the xsd to be updated. In turn, this should require the version
in the pom to be changed since it would be confusing to make a
modification without updating the xsd version. So in addition to having
to add <override>true</override> you would also have to change your pom
version to something like 4.0.1 and reference a different xsd.

Next in 2.1 presumably this element would be removed, so all the poms
where this was specified might not work any longer. But with so many
poms in a maven repository you can't really do that. 2.1 would be forced
to at least tolerate the element so that the builds would work.  Of
course, what would you do in 2.1 if you encountered a pom with
<override>false</override> explicitly specified?

Frankly, this seems worse than breaking compatibility in 2.0.x.

Given that, the only other alternatives seem to be system properties or
adding it to the settings. Neither of these is particularly attractive
because if someone tries to run the build and doesn't know to have the
option set then they will get different build results.

Ralph

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

[Jason van Zyl-2]

On 17 Mar 07, at 12:31 AM 17 Mar 07, Ralph Goers wrote:

> Jason van Zyl wrote:
>>
>> I will work with Patrick to put the old and new in 2.0.x. If it  
>> really comes down to turning it off by default, which would be an  
>> immense shame, then so be it and people will just have to turn it  
>> on. We'll just devise a very easy way to turn it on like a  
>> property in the top-level POM. We can't jump from 2.0.6 to a 2.1  
>> for this.
>>
>> Jason.
>>
> Jason,
>
> I would take the override option off the table.
>

I am still hoping this will go in as the default behavior and I would  
honestly be surprised if anyone disagrees after looking at the old  
versus new behavior. That said, if it gets vetoed then I was thinking  
a property in the POM that could get picked up.

> When I wrote the patch for MNG-1577 I added an override element to  
> the dependencyManagement element in the pom so backward  
> compatibility could be preserved. However, I realized later that  
> that change itself would cause problems. This is because adding  
> anything to the pom really requires the xsd to be updated. In turn,  
> this should require the version in the pom to be changed since it  
> would be confusing to make a modification without updating the xsd  
> version. So in addition to having to add <override>true</override>  
> you would also have to change your pom version to something like  
> 4.0.1 and reference a different xsd.
> Next in 2.1 presumably this element would be removed, so all the  
> poms where this was specified might not work any longer. But with  
> so many poms in a maven repository you can't really do that. 2.1  
> would be forced to at least tolerate the element so that the builds  
> would work.  Of course, what would you do in 2.1 if you encountered  
> a pom with <override>false</override> explicitly specified?
>
> Frankly, this seems worse than breaking compatibility in 2.0.x.

I agree. It would probably not be worth putting it in if it's not the  
default because no one will read anything and most likely will not  
enable the behavior.

>
> Given that, the only other alternatives seem to be system  
> properties or adding it to the settings. Neither of these is  
> particularly attractive because if someone tries to run the build  
> and doesn't know to have the option set then they will get  
> different build results.

Indeed. I'll make a build this weekend and let people try it out and  
hope that we'll put it into 2.0.6 and give it the proper label of a  
corrective of a fundamental defect.

Jason.

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


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

[Brian E Fox]

I whipped up a mojo to test a build for cases where the resolved
dependency is different than what is set in the dependencyManagement
section. Use maven-dependency-plugin 2.0-alpha-3-SNAPSHOT (deployed to
snapshot repo) run as "mvn dependency:analyze" and it will display
mismatches. It currently skips snapshots but any released artifacts that
don't match will cause a problem.

-----Original Message-----
From: Brett Porter [mailto:brett@...]
Sent: Friday, March 16, 2007 7:39 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior

Mike,

Good plan. This is exactly what I was getting at - but I thought we  
could already do this from the branch that the feature was  
implemented on? That's what I was intending to use.

I'm obviously having trouble grokking the actual implications of this  
- I was getting the clear impression this was going to break builds,  
but it seems that may not be the case from the ensuing discussion. So  
all I really want to do is play with it and see for myself at this  
point. I have some time later today/tomorrow.

- Brett

On 17/03/2007, at 7:35 AM, Mike Perham wrote:

> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade?  I would prefer to see less
> speculation and more bits.  Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread.  If no one has problems, this discussion becomes a lot
> shorter.  If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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


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

[Brian E Fox]

I meant to say:
It currently skips snapshots but any released artifacts that
don't match will potentially cause a problem with a build with MNG-1577
applied.

I'm hoping that we can get this fixed up, release the analyze test and
make MNG-1577 the default behavior. We can not only describe it clearly
in the release notes, but now we'll have a tool to have people run in
2.0.5 to identify issues BEFORE they upgrade.

-----Original Message-----
From: Brian E. Fox [mailto:brianf@...]
Sent: Saturday, March 17, 2007 1:11 AM
To: Maven Developers List
Subject: Mojo to test for MNG-1577 was [vote] MNG-1577 as the default
behavior

I whipped up a mojo to test a build for cases where the resolved
dependency is different than what is set in the dependencyManagement
section. Use maven-dependency-plugin 2.0-alpha-3-SNAPSHOT (deployed to
snapshot repo) run as "mvn dependency:analyze" and it will display
mismatches. It currently skips snapshots but any released artifacts that
don't match will cause a problem.

-----Original Message-----
From: Brett Porter [mailto:brett@...]
Sent: Friday, March 16, 2007 7:39 PM
To: Maven Developers List
Subject: Re: [vote] MNG-1577 as the default behavior

Mike,

Good plan. This is exactly what I was getting at - but I thought we  
could already do this from the branch that the feature was  
implemented on? That's what I was intending to use.

I'm obviously having trouble grokking the actual implications of this  
- I was getting the clear impression this was going to break builds,  
but it seems that may not be the case from the ensuing discussion. So  
all I really want to do is play with it and see for myself at this  
point. I have some time later today/tomorrow.

- Brett

On 17/03/2007, at 7:35 AM, Mike Perham wrote:

> The key question to me is: are existing 2.0.5 builds going to be
> better or worse after this upgrade?  I would prefer to see less
> speculation and more bits.  Put out a Maven 2.0.6 snapshot that people
> can try with their project and get reports from the people in this
> thread.  If no one has problems, this discussion becomes a lot
> shorter.  If they do have problems, at least we have specific examples
> to discuss.
>
> mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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


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


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

[Ralph Goers]

Jason van Zyl wrote:
>
> I will also help because we need a spec that people can read to
> understand what exactly happens. There is a fundamental level of
> confusion as to how snapshots work, how versions work where, and how
> you accurately control what versions get pulled in. Ralph, I would
> certainly work with you to make an APT or Confluence document.
> Wherever is fine with me.
>
> jason.
I've attached a new patch to mng-1577. It contains a patch to a couple
of the APT files for the web site. Please feel free to edit it if I have
gotten something wrong.  I've built the site with it so I know the
formatting is OK.

Ralph

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

[brettporter]

This doc looks good to me.

On 17/03/2007, at 7:11 PM, Ralph Goers wrote:

> Jason van Zyl wrote:
>>
>> I will also help because we need a spec that people can read to  
>> understand what exactly happens. There is a fundamental level of  
>> confusion as to how snapshots work, how versions work where, and  
>> how you accurately control what versions get pulled in. Ralph, I  
>> would certainly work with you to make an APT or Confluence  
>> document. Wherever is fine with me.
>>
>> jason.
> I've attached a new patch to mng-1577. It contains a patch to a  
> couple of the APT files for the web site. Please feel free to edit  
> it if I have gotten something wrong.  I've built the site with it  
> so I know the formatting is OK.
>
> Ralph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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

[Jorg Heymans-2]

Eric Redmond wrote:
> +1 for patching 2.0.6
>
> I have yet to hear a single convincing argument for maintaining
> broken behavior. Who cares if people depend on it being broken? Don't
> upgrade. It's a defect, not a feature change. Pushing this to a major
> version is way overkill.

+1

Jorg


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

[brettporter]

On 17/03/2007, at 1:37 AM, Jason van Zyl wrote:

>> No matter how bad the existing behaviour, it is consistent once in  
>> place.
>
> It's not consistent at all. It is totally erratic behavior,  
> completely defective and counter intuitive. All people are forced  
> to do is is continually override dependencies in child project to  
> get the right version.

Poor choice of words perhaps, but I wanted to be clear that this is a  
behaviour change, not a bugfix. I think we can possibly make an  
exception in this case, but we generally shouldn't be doing that in a  
point release.

>>
>> Our users must be able to trust point releases are safe upgrades.  
>> Let's start moving on putting out 2.1 milestone releases instead.
>
> I think this is a mistake and doesn't help our users. We have not  
> only the ITs (which are still not good enough but ...) Patrick made  
> an extensive set of tests plus we have users who have been watching  
> this issue for a year and can attest in the field to this being a  
> miserable situation. This is a solution to their problem.

Ok, I think I can accept that it's bad that we make people choke down  
alpha code to get this. But I think it's bad that we got into that  
scenario too, and it's probably time to start mapping out an actual  
2.1 release instead of more point releases beyond 2.0.6.

I'll address the issue itself in another mail.

- Brett

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

[brettporter]

I'm generally in favour now, but there are a couple of things I'd  
still like to explore first, please bear with me.

Having had the chance to review the new behaviour, I can't see any  
problems with applying it to current builds - I would expect it  
extremely rare to see a managed dependency in a build that also comes  
through transitively at present (and if so, it's probably the version  
you want). So I'm happy to make that exception to include it in a  
point release given the 2.1 code is alpha.

Back tracking just a little bit, though - I want to validate that  
this is the correct implementation method.

- is overloading the meaning of dependency management a problem? I'm  
almost certain we considered doing this around about the 2.0-alphas  
and it was ruled out, though personally I've always thought depMgmt  
should have behaved this way.
- is this covering up for a lack of something in the dependency  
mechanism itself? eg., if we add proper conflict resolution and  
different selection mechanisms, would this be needed/removed?

My impression is that we'd still want this in the future, but  
improvements to the mechanism itself should reduce the need for it in  
projects.  I just thought it was worth considering, since I thought  
it'd been ruled out for other reasons in the past. But other than  
that, I'm happy with it going in now.

As a last point, I'm a little confused about what we are actually  
voting on - as far as I can tell this is already the default  
behaviour on the branch? I must be missing something - what needs to  
be done?

Thanks for getting this done folks - it certainly has been a pest.

- Brett

On 17/03/2007, at 10:38 AM, Brett Porter wrote:

> Mike,
>
> Good plan. This is exactly what I was getting at - but I thought we  
> could already do this from the branch that the feature was  
> implemented on? That's what I was intending to use.
>
> I'm obviously having trouble grokking the actual implications of  
> this - I was getting the clear impression this was going to break  
> builds, but it seems that may not be the case from the ensuing  
> discussion. So all I really want to do is play with it and see for  
> myself at this point. I have some time later today/tomorrow.
>
> - Brett
>
> On 17/03/2007, at 7:35 AM, Mike Perham wrote:
>
>> The key question to me is: are existing 2.0.5 builds going to be
>> better or worse after this upgrade?  I would prefer to see less
>> speculation and more bits.  Put out a Maven 2.0.6 snapshot that  
>> people
>> can try with their project and get reports from the people in this
>> thread.  If no one has problems, this discussion becomes a lot
>> shorter.  If they do have problems, at least we have specific  
>> examples
>> to discuss.
>>
>> mike
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...

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

[Jason van Zyl-2]

On 17 Mar 07, at 8:34 AM 17 Mar 07, Brett Porter wrote:

> I'm generally in favour now, but there are a couple of things I'd  
> still like to explore first, please bear with me.
>
> Having had the chance to review the new behaviour, I can't see any  
> problems with applying it to current builds - I would expect it  
> extremely rare to see a managed dependency in a build that also  
> comes through transitively at present (and if so, it's probably the  
> version you want). So I'm happy to make that exception to include  
> it in a point release given the 2.1 code is alpha.
>
> Back tracking just a little bit, though - I want to validate that  
> this is the correct implementation method.
>
> - is overloading the meaning of dependency management a problem?  
> I'm almost certain we considered doing this around about the 2.0-
> alphas and it was ruled out, though personally I've always thought  
> depMgmt should have behaved this way.
> - is this covering up for a lack of something in the dependency  
> mechanism itself? eg., if we add proper conflict resolution and  
> different selection mechanisms, would this be needed/removed?
>

The depMan declarations now channels all transitive dependency to  
what the user specifies, but what we still need in the future when  
ranges become common place is the conflict resolution mechanism as  
we've always thought it would work. Because the overwhelming majority  
of people do not use ranges almost everyone would have their  
dependencies aligned by the dependency management section. The user  
could still be wrong because they may choose a version of a  
dependency that another project has deemed unfit to work with theirs.  
So the conflict resolution strategies will come into play when ranges  
are used and when we have a way to automatically detect real problems  
between versions like using CLIRR/JarDiff in a consistent way.

So in short this would not affect our long-term strategy of using  
conflict resolution strategies, and in the short term this provides a  
very use conflict resolution strategy which is "use what I say, dammit".

> My impression is that we'd still want this in the future, but  
> improvements to the mechanism itself should reduce the need for it  
> in projects.  I just thought it was worth considering, since I  
> thought it'd been ruled out for other reasons in the past. But  
> other than that, I'm happy with it going in now.

I definitely think resolution strategies will be necessary once  
people start actively using ranges. I would hope that at some point  
in the future we could deterministically a user has picked something  
that will not work because we know it's binary incompatible or out of  
range with the versions other projects are using.

>
> As a last point, I'm a little confused about what we are actually  
> voting on - as far as I can tell this is already the default  
> behaviour on the branch? I must be missing something - what needs  
> to be done?

Nothing, I was going to roll it back out if there were any -1s at the  
end of the discussion.

>
> Thanks for getting this done folks - it certainly has been a pest.
>

If we get it in, I think folks will be very happy even if they don't  
know it ever went in.

Jason.

> - Brett
>
> On 17/03/2007, at 10:38 AM, Brett Porter wrote:
>
>> Mike,
>>
>> Good plan. This is exactly what I was getting at - but I thought  
>> we could already do this from the branch that the feature was  
>> implemented on? That's what I was intending to use.
>>
>> I'm obviously having trouble grokking the actual implications of  
>> this - I was getting the clear impression this was going to break  
>> builds, but it seems that may not be the case from the ensuing  
>> discussion. So all I really want to do is play with it and see for  
>> myself at this point. I have some time later today/tomorrow.
>>
>> - Brett
>>
>> On 17/03/2007, at 7:35 AM, Mike Perham wrote:
>>
>>> The key question to me is: are existing 2.0.5 builds going to be
>>> better or worse after this upgrade?  I would prefer to see less
>>> speculation and more bits.  Put out a Maven 2.0.6 snapshot that  
>>> people
>>> can try with their project and get reports from the people in this
>>> thread.  If no one has problems, this discussion becomes a lot
>>> shorter.  If they do have problems, at least we have specific  
>>> examples
>>> to discuss.
>>>
>>> mike
>>>
>>> --------------------------------------------------------------------
>>> -
>>> To unsubscribe, e-mail: dev-unsubscribe@...
>>> For additional commands, e-mail: dev-help@...
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

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

[Ralph Goers]

See Below

Brett Porter wrote:

> I'm generally in favour now, but there are a couple of things I'd
> still like to explore first, please bear with me.
>
> Having had the chance to review the new behaviour, I can't see any
> problems with applying it to current builds - I would expect it
> extremely rare to see a managed dependency in a build that also comes
> through transitively at present (and if so, it's probably the version
> you want). So I'm happy to make that exception to include it in a
> point release given the 2.1 code is alpha.
>
> Back tracking just a little bit, though - I want to validate that this
> is the correct implementation method.
>
> - is overloading the meaning of dependency management a problem? I'm
> almost certain we considered doing this around about the 2.0-alphas
> and it was ruled out, though personally I've always thought depMgmt
> should have behaved this way.

I wasn't around for those discussions. However, before I started writing
the patch I searched the archives and never could find where these
decisions were made. Maybe I didn't look hard enough or perhaps there
were conversations off the list.

In any case, dependencyManagement seems to infer to me explicitly
managing dependencies. This patch obviously does that. The behavior
before was more of a suggestion than actual management.
> - is this covering up for a lack of something in the dependency
> mechanism itself? eg., if we add proper conflict resolution and
> different selection mechanisms, would this be needed/removed?
I don't think so. I think Maven does the best it can with transitive
dependencies, but with large projects there are bound to be conflicts
that require a person to make a choice.
>
> My impression is that we'd still want this in the future, but
> improvements to the mechanism itself should reduce the need for it in
> projects.  I just thought it was worth considering, since I thought
> it'd been ruled out for other reasons in the past. But other than
> that, I'm happy with it going in now.
In my environment (Maven 1) we use jar overrides to explicitly specify
the version of every artifact to use. Our Configuration Management folks
want it that way. With Maven 2 this just becomes a much better way to
accomplish that since the pom containing the managed dependencies can be
shared much easier than a build.properties file.
>
> As a last point, I'm a little confused about what we are actually
> voting on - as far as I can tell this is already the default behaviour
> on the branch? I must be missing something - what needs to be done?
What you are voting on is allowing it to go into the next release as-is
knowing that it is not 100% backward compatible.
>
> Thanks for getting this done folks - it certainly has been a pest.
You're welcome. It was fun and a great example of how OSS is supposed to
work. I wrote the patch and then Patrick took it into his environment
and corrected a few mistakes, added some more unit tests and then
checked it out on their projects.

Ralph

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