我目前有一个仅在编译时需要依赖的SBT子项目,所以我认为它是使用intransitive
的好地方,因此使用它的项目不需要下载那种依赖。
然而,根据SBT reference manual:
在某些情况下,您可能会发现为项目列出的依赖项不是构建项目所必需的。例如,使用Felix OSGI框架的项目仅明确要求其主jar进行编译和运行。避免使用intransitive()或notTransitive()
获取工件依赖项
措辞有点令人困惑,因为它不鼓励使用transitive()
或notTransitive()
而不解释为什么或何时(始终?)。
答案 0 :(得分:5)
我认为你只是误读了这句话。 “避免使用intransitive()或notTransitive()获取工件依赖关系”意味着“如果您想避免获取工件依赖关系,那么执行此操作的方法是使用intransitive()或notTransitive()”。
答案 1 :(得分:3)
notTransitive
只是intransitive
的别名,定义如下:
def notTransitive = intransitive
Configuration.scala中的。这只是一个偏好问题,例如Specs2中的must
和should
,或Scala集合中的size
和length
。
通常使用默认的传递依赖行为是首选,因为它需要较少的配置和维护 - SBT将为您提取所有必需的依赖项。如果您决定升级主要依赖项的版本,则也不必手动升级所有传递依赖项。但是,有时您不需要在某些范围内具有依赖关系,例如Specs2
通常只适用于test
范围。在其他情况下,您的环境提供了所有必需的依赖项,您可以通过不打包来使您的打包工件更小。传递依赖管理适合大多数用例,并且在运行时(缺少实现,未找到类)中导致更少的错误,这就是它的首选原因。如果您知道自己在做什么,那么使用intransitive
选项并没有错。
请注意,通过在依赖项上设置intransitive
,如果它依赖于项目的库依赖项,则仍然会获取该依赖项。您只是避免获取其传递/子依赖项。
如果您的SBT子项目使用该依赖项构建正常,而您的其他SBT项目使用该子项目而不直接需要该依赖项,那么就不要将该库依赖项包含到第二个项目中。在这种情况下,你不需要做不及时的conf。
在您的情况下,它听起来像依赖项目或环境将提供那些传递依赖。在这种情况下,如果您在技术上只是针对像Servlets或某些日志库这样的API进行编译,请使用intransitive
。
答案 2 :(得分:2)
intransitive
,因为:
provided
保留用于预期依赖项在运行时中,例如一个应用程序容器。
对于运行时不需要依赖的情况,我会保留intransitive
,仅在编译时。例如编译器注释
答案 3 :(得分:1)
这是"提供"的完美用例。组态。在您的项目中,依赖于"provided"
配置中的库(例如' foo'),如下所示:
libraryDependencies += "org.foo" %% "foo" % "1.0" % "provided"
这将在编译时将foo
添加到类路径,但不会在工件的元数据(pom)中注册"org.foo" %% "foo" % "1.0"
。因此,您项目的用户不会依赖于foo,只是因为他们根本不会看到它。