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 <
[email protected]>:

> 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 <[email protected]>
> 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?
> >
>

Reply via email to