Why and / or when should you avoid intransitive () or notTranstive ()?

I currently have an SBT subproject that only requires a compile-time dependency, so I find it a useful place to use intransitive

so that projects that use it won't need to load that dependency.

However, according to the SBT reference guide :

In some cases, you may find that the dependencies required by the project are required to build it. For example, projects using the OSGI Felix framework explicitly require its main jar to be built and run. Avoid sampling artifacts with either intransitive () or notTransitive ()

The wording is a bit confusing as it discourages use transitive()

or notTransitive()

without explaining why and when (all the time?).


source to share

4 answers


discouraged because:

  • downstream users do not see this in their POM and this can break their runtime,
  • even if they know which dependency to add, its version will not sync up with the upstream.


reserved when a dependency is expected to reside at runtime, eg. application container.

I would reserve intransitive

for cases where the dependency is not needed at runtime, only at compile time. e.g. compiler annotations



I think you are just reading the sentence wrong. "Avoid getting artifact dependencies with either intransitive () or notTransitive ()" means "If you want to avoid fetching artifacts, the way to do it is with either intransitive () or notTransitive ()".




is just an alias intransitive

and is defined like this:

def notTransitive = intransitive


in Configuration.scala . It's just a matter of preference, the type must

and should

in Specs2, or size

and length

in Scala collections.

Generally, using the default transitive dependency behavior is preferred because it requires less configuration and maintenance - SBT will pull all the required dependencies for you. If you choose to update the version of the primary dependency, you also do not need to manually update all transitive dependencies. However, sometimes you may or may not need to have a dependency in some areas, for example Specs2

should usually only be available for the areatest

... In other cases, your environment provides all the required dependencies, and you can make your packaged artifact smaller without packaging them. Transit dependency management is fine for most use cases and results in less runtime errors (no implementation, no class found) and why it prefers. If you know what you are doing, there is nothing wrong with using the option intransitive


Note that when installing intransitive

as a dependency, you still retrieve this dependency if it is in the library's library dependencies. You avoid getting your transitive / helper dependencies.

If your SBT subproject builds fine with this dependency, and your other SBT project uses this subproject without requiring this dependency directly, simply don't include that library dependency in the second project. In this case, you don't need to do non-transient conf.

In your case, this sounds like dependent projects or an environment providing these transitive dependencies. Use in this case intransitive

if you are technically just compiling an API like servlets or some log library.



This is the ideal use case for the "provided" configuration. In your project, depend on a library (say "foo") in the config "provided"

like this:

libraryDependencies += "org.foo" %% "foo" % "1.0" % "provided"


This will add foo

to the classpath at compile time, but will not register "org.foo" %% "foo" % "1.0"

in the metadata (pom) of your artifact. Therefore, users of your project will not depend on foo, simply because they cannot see it at all.



All Articles