I think I understand now. You're saying MyProject requires X for testing and Y for compiling, but Y also requires X for compiling, thus X is a transitive compile-time (or at least runtime) dependency of MyProject, incidentally (not directly). Maven is not interpreting your input that way.
You mean to tell Maven that MyProject requires X _in addition to_ other dependencies specified, but Maven interprets that as _overriding_ or _replacing_ the transitive dependency. If I understand correctly, your original post was saying that seems worng or at least needlessly opens the door to mistakes which a different design could prevent. E.g. if Maven required you to use an exclusion to remove a dependency instead of allowing you to quietly override a dependency with a weaker scope, then you could _just_ specify what a project needs directly, and Maven would figure out the details or fail the build if what you ask for has an ambiguity with no safe, meaningful default resolution. Hope that makes sense. On Wed, May 15, 2019 at 12:42 AM Simon Taddiken <simon.taddi...@gmail.com> wrote: > 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? > > > > >
