There might be a rule in the enforcer plugin (I haven't checked). If one really wanted to change the dependency scope, he could add an exclusion in the Y dependency to break the transitivity.
Fwiw, whenever you change your dependencies, it's a good idea to run mvn dependency:tree and look at the output (possibly diff'ing it with the output prior to the dependency change). Maven basically assumes that you take responsibility for the dependencies, and it only takes the role of a helper resolving the whole tree. Le mer. 15 mai 2019 07:42, Simon Taddiken <simon.taddi...@gmail.com> a écrit : > In my case, the pom of Y explicitly declares X with scope compile. The > dependency tree should look something like this: > > MyProject <- this is a standalone application, that will not be depended on > by s/o else > |- X:test > |- Y:compile > \- X:compile > > So for MyProject, X is explicitly declared test but X also comes in > transitively via Y as compile. I do understand that declarations higher in > the tree are given precedence when it comes to dependency resolution but in > this case it simply breaks runtime code. > Of course I did not want to ship MyProject including X when I used X only > for tests. But now that Y also requires X I need MyProject to ship with X > in order to work correctly. > > I was just wondering whether there is some mechanism like a warning or a > flag to break the build in such cases, so that they do not go unnoticed. > > > Am Di., 14. Mai 2019 um 22:22 Uhr schrieb Jason Young < > jason.yo...@procentive.com>: > > > Did you declare that Y depends on X at all (via Y's pom.xml) or did it > > figure that out on its own (via transitive dependencies)? > > > > Test scope means it's for testing that one project, thus it's not > > transitive, e.g. I don't need JUnit for my tests just because > > SomeAwesomeProject uses JUnit for its tests, and I don't want to ship > JUnit > > in my project. > > > > On Tue, May 14, 2019 at 2:40 PM Simon Taddiken <simon.taddi...@gmail.com > > > > wrote: > > > > > Hi everyone, > > > > > > I've encountered the following behavior and I'm not quite sure whether > it > > > is desirable. > > > In my project, I have declared a dependency *X* with scope *test*. I > then > > > updated the version of a 3rd party dependency *Y*. In its new version, > > *Y* > > > suddenly requires the aforementioned dependency *X* as a *compile > *scoped > > > dependency. > > > > > > In this scenario, maven resolves the scope of *X* to be *test, > *although > > it > > > is now required by *Y* during runtime, causing ClassNotFoundExceptions. > > By > > > the very nature of this behavior those mistakes can't even be detected > in > > > unit tests because *X* is available on test classpath. > > > > > > I have just found out that this behavior seems to be intended ( > > > > > > > > > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope > > > ) > > > but I can't really come up with a rationale for this design. Managing > any > > > transitive compile scoped dependency down to test scope will almost > > > certainly cause ClassNotFoundExceptions during runtime. > > > > > > Thoughts? > > > > > >
