-
We're using Play with Scala in our project. I don't know much sbt, but does it have a way to get transitive dependencies automatically? For example, from my build.sbt: // (among others)
libraryDependencies += jdbc Clearly there's some level of knowledge it has about transitive dependencies, such as in the output of
(slf4j-api appears in many other places in addition to the snippet above) (I just realized But when I use
I also tried looking at the output of It would be best if I didn't have to list all the transitive dependencies in build.sbt. But will I have to after all? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 16 replies
-
Transitive dependencies are fetched automatically, you don't have to do anything. |
Beta Was this translation helpful? Give feedback.
-
As @mkurz says, sbt should deal with transitive dependencies automatically. So the sort of error you're seeing here is usually caused by conflicting dependencies, where Play and your libraries depend on different versions of the transitive dependency -- only one can actually be loaded, so you can get runtime crashes like this because a library is trying to call a function or invoke a class that doesn't exist in the version of the dependency that actually wound up linked in. (This is what those eviction warnings are about, in the output you included. Note for example that jdbcdslog depends on slf4j 1.5.10, but what actually got loaded is version 1.7.33.) In practice, the best way to avoid this is usually to make sure you have the most up-to-date version of all of your direct dependencies -- if they are all being actively maintained, that tends to avoid this sort of incompatible-version collision. |
Beta Was this translation helpful? Give feedback.
-
That's interesting, thanks for the info. I saw that there was some documentation on the default conflict resolution being to use the highest version, and I take it that the "1.7.33" and earlier versions being "evicted" to mean that this has taken place. But other than the actual interoperability issues between versions of slf4j-api (actually should be fine, to my understanding), I should at least see the 1.7.33 version of slf4j-api in the classpath, right? I'm on the latest sbt, but I'm going to try updating to the latest play as well. I realize there's not enough here to reproduce the issue as is. Thanks for answering without feeling that you need to solve the issue for me. I am seeking (i) general strategies for troubleshooting this sort of thing (ii) feedback on whether I'm reading these printouts right, e.g. what does that |
Beta Was this translation helpful? Give feedback.
-
I updated several dependencies in places where we have access. The result is that the app gets as far as starting up, and there are no more complaints about slf4j. But this turned out not to be the only classpath issue. Here's more of the same genre of issue, coming during the first request:
Which again, in various places in the dependency tree:
( As before, that jar is absent from the This time there isn't even any conflicts or "evicted" going on for this one. |
Beta Was this translation helpful? Give feedback.
Transitive dependencies are fetched automatically, you don't have to do anything.
Which version of sbt are you using?
Also please upgrade to latest Play 2.8.15.