[vote] MNG-1577 as the default behavior

[Ralph Goers]

Jason van Zyl wrote:

>
> 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.

Yes, but here you have some overlap with jsr 277 and OSGi. As a
developer I wouldn't want to have to specify this stuff in multiple places.

It would be great if the build could fail if incompatible versions are
being used. It would be even better if the classloader allowed multiple
versions of an artifact to exist in the JVM. Imagine that you could
specify a version range that this jar supports in the manifest and that
other jars could specify a version range that they require in their
manifest. Then the classloader could namespace these and choose the best
version match.

>
> 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.

Yes, that would be a great help.

Ralph

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

[Brian E Fox]

Going through my builds, I'm finding a surprising number of mismatches.
Looks like I've got some significant cleanup to do. Here's some sample
output:
[INFO] [dependency:analyze]
[INFO] Found Resolved Dependency / DependencyManagement mismatches:
[INFO]  Dependency: oracle:adf-faces-api:jar
[INFO]          DepMgt  : 20.5-STCEA
[INFO]          Resolved: 10.1.3.0.4
[INFO]  Dependency: javax.servlet:servlet-api:jar
[INFO]          DepMgt  : 2.3
[INFO]          Resolved: 2.4
[INFO]  Dependency: junit:junit:jar
[INFO]          DepMgt  : 3.7
[INFO]          Resolved: 3.8.1
[INFO]  Dependency: oracle:adf-faces-impl:jar
[INFO]          DepMgt  : 20.5-STCEA
[INFO]          Resolved: 10.1.3.0.4
[INFO]  Dependency: commons-lang:commons-lang:jar
[INFO]          DepMgt  : 1.0
[INFO]          Resolved: 2.3
[INFO]  Dependency: commons-digester:commons-digester:jar
[INFO]          DepMgt  : 1.5
[INFO]          Resolved: 1.7

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

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@...


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

[Jörg Schaible]

Hi Brian,

Brian E. Fox wrote on Saturday, March 17, 2007 6:11 AM:

> 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.

You know that this goal clashes with the branch of the branch of the dependency plugin in the sandbox?

- Jörg

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

[Trygve Laugstøl apache]

Jason van Zyl 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.

It seems that this discussion has settled down by now and I'm fine with
the conclusion you guys have come up with.

However, I would like to make one point. I see that the discussion has
been confused with

  silly/dump/whatever dependency resolution

vs

  silly/dump/whatever, but *predictable*, dependency resolution.

If this patch would in any way change dumb, silly, retarded, awkward
*predictable* dependency resolution I would have voted -1 to it. We
cannot change the behavior in a bugfix release, no matter how trivial
and "sane" it will be. We just can't do it. Adding an option to enable
the good method would be a way around, and it *might* be done in a 2.1
release as it would make life better for everyone, but even then we're
violating the rules of never changing behavior.

I would like comments on this *philosophy*, not the issue in question.

A workaround for this would be to change the XSD and say that the XSD
specifies the behavior which is the only thing that makes sense to me.
The model version should imply behavior.

--
Trygve

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

[Jason van Zyl-2]

On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:

> Jason van Zyl 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.
>
> It seems that this discussion has settled down by now and I'm fine  
> with the conclusion you guys have come up with.
>
> However, I would like to make one point. I see that the discussion  
> has been confused with
>
>  silly/dump/whatever dependency resolution
>
> vs
>
>  silly/dump/whatever, but *predictable*, dependency resolution.
>
> If this patch would in any way change dumb, silly, retarded,  
> awkward *predictable* dependency resolution I would have voted -1  
> to it.

It's entirely not predictable. Anyone asked how they thought depMan  
works would answer in accordance with the work in MNG-1577. They do  
not expect the behavior that is there before it.

> We cannot change the behavior in a bugfix release, no matter how  
> trivial and "sane" it will be. We just can't do it. Adding an  
> option to enable the good method would be a way around, and it  
> *might* be done in a 2.1 release as it would make life better for  
> everyone, but even then we're violating the rules of never changing  
> behavior.
>
> I would like comments on this *philosophy*, not the issue in question.

In theory I would agree. But we've gone against this several times.

>
> A workaround for this would be to change the XSD and say that the  
> XSD specifies the behavior which is the only thing that makes sense  
> to me. The model version should imply behavior.

The problem here is that a static model cannot imply the behavior of  
a dynamic system.

In this case the XSD would be exactly the same would describe nothing  
regarding how one dependency is selected over another. The static  
model cannot reflect dynamic nature of artifact resolution.

Unless you are referring to something in the model which said what it  
was going to do and as we discussed (Ralph brought it up) that it  
would be a maintenance nightmare. What we would ultimately have to  
express in this case is that we were wrong and not providing the  
behavior that anyone expects and that we had corrected it. Cumbersome  
instead of providing a default mechanism that does the right thing.  
In this case we're fortunate that it will bring far more benefit then  
harm. I think we've done the right thing in this case and the result  
will be users will be better off.

Jason.

>
> --
> Trygve
>
> ---------------------------------------------------------------------
> 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@...

[Trygve Laugstøl apache]

Jason van Zyl wrote:

>
> On 20 Mar 07, at 7:45 AM 20 Mar 07, Trygve Laugstøl wrote:
>
>> Jason van Zyl 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.
>>
>> It seems that this discussion has settled down by now and I'm fine
>> with the conclusion you guys have come up with.
>>
>> However, I would like to make one point. I see that the discussion has
>> been confused with
>>
>>  silly/dump/whatever dependency resolution
>>
>> vs
>>
>>  silly/dump/whatever, but *predictable*, dependency resolution.
>>
>> If this patch would in any way change dumb, silly, retarded, awkward
>> *predictable* dependency resolution I would have voted -1 to it.
>
> It's entirely not predictable. Anyone asked how they thought depMan
> works would answer in accordance with the work in MNG-1577. They do not
> expect the behavior that is there before it.
>
>> We cannot change the behavior in a bugfix release, no matter how
>> trivial and "sane" it will be. We just can't do it. Adding an option
>> to enable the good method would be a way around, and it *might* be
>> done in a 2.1 release as it would make life better for everyone, but
>> even then we're violating the rules of never changing behavior.
>>
>> I would like comments on this *philosophy*, not the issue in question.
>
> In theory I would agree. But we've gone against this several times.

When?

In this case there was talk about changing behavior that would
potentially break existing builds as it wasn't determined if it was
predictable or not.

>>
>> A workaround for this would be to change the XSD and say that the XSD
>> specifies the behavior which is the only thing that makes sense to me.
>> The model version should imply behavior.
>
> The problem here is that a static model cannot imply the behavior of a
> dynamic system.
>
> In this case the XSD would be exactly the same would describe nothing
> regarding how one dependency is selected over another. The static model
> cannot reflect dynamic nature of artifact resolution.
>
> Unless you are referring to something in the model which said what it
> was going to do and as we discussed (Ralph brought it up) that it would
> be a maintenance nightmare. What we would ultimately have to express in
> this case is that we were wrong and not providing the behavior that
> anyone expects and that we had corrected it. Cumbersome instead of
> providing a default mechanism that does the right thing. In this case
> we're fortunate that it will bring far more benefit then harm. I think
> we've done the right thing in this case and the result will be users
> will be better off.

Ok, using the model version is quite possibly wrong but there
could/should be a field indicating the expected behavior making room for
these kind of changes. An alternative is to take a look at the required
Maven version to use that as pointer to which behavior to use.

Leaving the specifics of this issue, imagine what will happen if the
plan of very frequent (<1 month) release intervals will be implemented
and within the next two years there will be 20 Maven releases (all most
likely with 2 as it's major version). If the behavior suddenly changes
randomly between point releases people will suffer way more as everyone
in a team has to standardize on a certain Maven version and then we've
suddenly lost a lot of the things we wanted to gain by putting a version
field on everything. By having such a high number of releases you can be
sure people will use the different versions all the time.

I cannot stress the need to keep the behavior *very* stable. A dump (but
not wrong) choice made by a developer should not be allowed to suddenly
break (clumsy) but working builds.

--
Trygve

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