We need to clarify. There is stuff that is "wrong" but has become expected behaviour because we never "fixed" it => we cannot "fix" now because it will break too many users
There is stuff that is "wrong" because we broke it, some users have legitimate bugs and other users have hacks around the "wrong" => we will break something no matter what we do, so maybe we can "fix" There is stuff that is "wrong" because it was never specified and we'd now like it to work one way because that way feels "right" Etc What class of problem is this? To my mind, depMgmt should never alter the scope of a dependency... if you specify a scope you are saying apply the rest when it is added with this scope. But that is my "how I would like it to work"... Christian, you need to identify which kind of "wrong" behaviour is going on here... then we can reframe the debate and find a path forward - Stephen On Sun 18 Dec 2016 at 23:52, Christian Schulte <c...@schulte.it> wrote: > Am 12/18/16 um 13:36 schrieb Robert Scholte: > > > On Fri, 16 Dec 2016 21:23:14 +0100, Christian Schulte <c...@schulte.it> > > > wrote: > > > > > >> Am 12/16/16 um 20:30 schrieb Robert Scholte: > > >>> On Fri, 16 Dec 2016 17:25:16 +0100, Christian Schulte <c...@schulte.it> > > >>> wrote: > > >>> > > >>>> Am 12/16/16 um 15:21 schrieb Robert Scholte: > > >>>>> > > >>>>> but this cover the issue we are talking about, because IIUC you are > > >>>>> saying > > >>>>> that IF both junit and hamcrest get the test-scope AND hamcrest would > > >>>>> have > > >>>>> a dependency THEN that dependency is not added to the classpath. That > > >>>>> is > > >>>>> still unexpected behavior. > > >>>> > > >>>> Just add 'test' scope to the hamcrest dependency in that pom. It will > > >>>> disappear from the classpath. I would expect that to happen. Why > should > > >>>> it manage the version but not the scope? > > >>>> > > >>> > > >>> Because Junit refers to hamcrest classes, so they are required to be > > >>> able > > >>> to compile. > > >>> There is an issue about this, that Maven should never reduce the scope. > > >> > > >> It's not Maven reducing any scope, it's the user telling Maven to do > > >> that. The user is the dependency manager, not Maven. > > >> > > > > > > No, no, no. Dependency management may never make dependencies disappear, > > > no matter the scope specified. If a user doesn't want a dependency, it > > > must use dependency.excludes. > > > > Managing the scope of a dependency to 'test' Maven must behave the same > > way as if the dependency had been declared 'test' directly in the POM. > > That's the point. That's what dependency management is used for. Manage > > dependencies not in your control (global override to what is in the POM > > during resolution). > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > -- Sent from my phone
