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
intransitive
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.
provided
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
source to share
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.
source to share
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.
source to share