maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason van Zyl <ja...@takari.io>
Subject Re: [MNG-5761] Dependency management is not transitive.
Date Tue, 15 Nov 2016 22:41:03 GMT

> On Nov 15, 2016, at 12:31 PM, Christian Schulte <cs@schulte.it> wrote:
> 
> Am 11/15/16 um 17:17 schrieb Jason van Zyl:
>> -1
>> 
>> No one has likely to have read the information
> 
> The reporter of the issue clearly has ;-)
> 
>> and you’re reasoning is illogical.
> 
> Making Maven behave as advertised and as requested isn't that illogical,
> IMHO.
> 

How it’s advertised is how it’s currently distributed and been working for years. You
think it’s logical the code to match documentation versus changing the documentation to
match what has been working in a specific say for years?

>> Repeatedly you seem not to care if you’re going to break a users build because
of lack of adherence to what you think is right.
> 
> The builds already are broken.

Define broken? You’re saying people are using this as-is and their builds are failing?

> I do not want the dependency management
> of a library I consume to be ignored by Maven making the dependency
> graph the way it gets consumed differ to what it looked like when
> deployed. Not only the reporter noticed this. See below. We could put
> that the other way around by saying "you seem not to care to fix broken
> builds" but that's just unproductive and leads to nowhere. There is at
> least one reporter who created an issue in JIRA telling us his builds
> are not working as advertised and who has put effort into reporting this
> to us. Having looked at it, that guy is just right. Working on it, I ran
> into an IT [1] starting to fail carrying this comment:
> 
> "should better have been excluded as well, now it's a matter of
> backward-compat"
> 
> So the author of that IT already knew things aren't correct but has kept
> things the way they were for Maven 2 backwards compatibility. I wish he
> would have fixed that six years ago, by the way.
> 

So you’re going to base your change in a minor version based on one reporter? 

>> What’s “right” is the way it currently works within this minor
>> version.
> 
> I take this as an example of what I am trying to stop.
> 

You obviously don’t work with anyone who has a system with any number of users. No one has
said the system cannot change, but you repeatedly keep changing stuff that potentially has
huge impacts on users and it doesn’t bother you at all. I just really don’t think you’ve
ever had to deal with more than a few users. Almost none of the changes are well documented,
there’s no release notes, we’ve told you to roll back or stop making behavioral changes.
It currently may not be ideal, we all may consider it’s a bug, or we may all agree it’s
wrong. A minor version is not the time or place to change it.

> 1. MNG-4720 created 08/Jul/10 14:48
> 2. IT capturing the known misbehaviour created 2010-07-08
> 3. MNG-5761 created 04/Feb/15 13:24
> 4. Fixed by me in mid 2016
> 5. Reverted and postponed for maybe 3.5 or 5.0 or whenever.
> 
> That's a history repeating. There is a - I guess - *new* user starting
> to use Maven. That user has read the documentation and that has created
> various expectations on how things are behaving.

Then fix the docs.

> That user then tests
> his builds and starts wondering why things are not working as expected.

To assume this happens on a wide scale is speculation.

> Puts effort into reporting an issue we know exists for - as of today -
> six years. We need to find a way out of this so that *new* users do no
> longer run into issues we could have fixed nearly a decade ago but did
> not. Maven 2 is EOL. We have not fixed Maven 2 misbehaviour in Maven 3.
> So we should EOL Maven 3 and provide something fixing those things finally.

Such is life. Again if you want to make drastic changes take all your changes and put them
on a 4.0 branch and do whatever you want. It’s an open source project so you’re free to
do so. Changing behavior and changing tests that validate that behavior is just really such
a bad, bad idea. Please go make a 4.0 branch and feel free to do whatever you want.

> 
> [1]
> <https://git-wip-us.apache.org/repos/asf?p=maven-integration-testing.git;a=blob;f=core-it-suite/src/test/java/org/apache/maven/it/MavenITmng4720DependencyManagementExclusionMergeTest.java;h=752ef8763893955f07ac48e0ced2cb86edae0ec8;hb=HEAD#l68>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder, Takari and Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
---------------------------------------------------------



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


Mime
View raw message