为什么和/或何时避免transitive()或inTransitive()?

时间:2014-10-02 01:13:48

标签: sbt

我目前有一个仅在编译时需要依赖的SBT子项目,所以我认为它是使用intransitive的好地方,因此使用它的项目不需要下载那种依赖。

然而,根据SBT reference manual

  

在某些情况下,您可能会发现为项目列出的依赖项不是构建项目所必需的。例如,使用Felix OSGI框架的项目仅明确要求其主jar进行编译和运行。避免使用intransitive()或notTransitive()

获取工件依赖项

措辞有点令人困惑,因为它不鼓励使用transitive()notTransitive()而不解释为什么或何时(始终?)。

4 个答案:

答案 0 :(得分:5)

我认为你只是误读了这句话。 “避免使用intransitive()或notTransitive()获取工件依赖关系”意味着“如果您想避免获取工件依赖关系,那么执行此操作的方法是使用intransitive()或notTransitive()”。

答案 1 :(得分:3)

notTransitive只是intransitive的别名,定义如下:

def notTransitive = intransitive
Configuration.scala中的

。这只是一个偏好问题,例如Specs2中的mustshould,或Scala集合中的sizelength

通常使用默认的传递依赖行为是首选,因为它需要较少的配置和维护 - SBT将为您提取所有必需的依赖项。如果您决定升级主要依赖项的版本,则也不必手动升级所有传递依赖项。但是,有时您不需要在某些范围内具有依赖关系,例如Specs2通常只适用于test范围。在其他情况下,您的环境提供了所有必需的依赖项,您可以通过不打包来使您的打包工件更小。传递依赖管理适合大多数用例,并且在运行时(缺少实现,未找到类)中导致更少的错误,这就是它的首选原因。如果您知道自己在做什么,那么使用intransitive选项并没有错。

请注意,通过在依赖项上设置intransitive,如果它依赖于项目的库依赖项,则仍然会获取该依赖项。您只是避免获取其传递/子依赖项。

如果您的SBT子项目使用该依赖项构建正常,而您的其他SBT项目使用该子项目而不直接需要该依赖项,那么就不要将该库依赖项包含到第二个项目中。在这种情况下,你不需要做不及时的conf。

在您的情况下,它听起来像依赖项目或环境将提供那些传递依赖。在这种情况下,如果您在技术上只是针对像Servlets或某些日志库这样的API进行编译,请使用intransitive

答案 2 :(得分:2)

不鼓励

intransitive,因为:

  • 下游用户不会在他们的POM中看到它,并且可能会破坏他们的运行时间,
  • 即使他们知道要添加的依赖项,其版本也不会与上游同步。

provided保留用于预期依赖项在运行时中,例如一个应用程序容器。

对于运行时不需要依赖的情况,我会保留intransitive,仅在编译时。例如编译器注释

答案 3 :(得分:1)

这是"提供"的完美用例。组态。在您的项目中,依赖于"provided"配置中的库(例如' foo'),如下所示:

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

这将在编译时将foo添加到类路径,但不会在工件的元数据(pom)中注册"org.foo" %% "foo" % "1.0"。因此,您项目的用户不会依赖于foo,只是因为他们根本不会看到它。