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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
