sbt中库与插件依赖的不同导入处理策略
最近，我发现SBT的一个有趣的问题。我很难用几句话来描述它，所以下面是我所做的几个步骤。
我有一些scala任务要部署。我把它发布到我们本地的nexus repo中，所以有几个项目可以使用它。下面是内部nexus回购的屏幕截图
因此，我将其放入build.sbt文件。
“sbt.LiquiBase”%“**sbt-LiquiBase-Deploy”%“1.0-3”**
它失败于未解决的依赖，我对此很好。但是，在那之后，我认为这个任务应该是一个插件，所以我可以在build.sbt文件中使用它。我将设置sbtplugin：true添加到任务中。在我发布它之后，该工件从sbt-liquibase-deploy_2.10更改为sbt-liquibase-deploy_2.10_0.13。基本上，sbt版本是附加的。
当我尝试addPlugin使用这些代码时
它在未解析的依赖项上失败
addSbtPlugin（“sbt.LiquiBase”%“sbt-LiquiBase-Deploy_2.10_0.13”%“1.0-3”）
它在未解析的依赖项上也失败了
addSbtPlugin（“sbt.LiquiBase”%“sbt-LiquiBase-Deploy”%“1.0-3”）//成功
我有三个问题。
>
为什么库依赖项需要scala版本而插件依赖项不需要。修好它花了几个小时。并不一致。
当我使用sbt发布任务时，scala版本和sbt版本是附加的，我可以定制它来摆脱它吗。
这是完全不相关的，是build.sbt和plugins.sbt中的解析器相同或不同。我问的原因是，当我尝试重新加载sbt时，会验证plugins.sbt中的解析器，而sbt update时，会验证build.sbt中的解析器
任何答案或解决方案都是赞赏的。：）
共有1个答案
>
插件是针对特定的sbt版本编译的，该版本使用特定的Scala版本。因此，addsbtplugin将在引擎盖下添加一个sbt和Scala版本。
你真的不应该这么做，因为第一个。您的插件是根据Scala和sbt的特定版本编译的，因此附加了这些值。
Sbt是递归的，build.Sbt中定义的解析器用于生成项目，project/plugins.Sbt中定义的解析器用于生成项目的生成定义。
-
我有一个sbt插件项目，使用多项目构建。我想使用这个插件作为其他sbt项目的依赖项。我已经创建了一个插件，但是当我把这个插件添加到project中时，我似乎不能正确地连接依赖项。 我在这里漏掉了什么？
-
Maven允许使用导入范围将依赖项（例如导入Spring Boot依赖项）导入到具有不同父级的项目中。这对插件管理有何影响？ 我想使用
-
最近，我发现了以下问题： 当我为我的项目设置依赖项管理时，我有一个child-pom，它使用具有依赖项的插件，我想要与在我的依赖项管理中声明的依赖项同步。 在根pom中,我在依赖项管理中声明： 在子pom中，我有一个插件需要gwt-user： 但是，如果我移除gwt-maven-plugin中使用的依赖版本，编译就会失败。 是不是还有别的办法可以实现呢？ PS：在maven和maven插件中有一个
-
我有一个Play应用程序，当我运行时，我得到一个错误，如下所示： 但实际上，这个插件的路径是而不是失败的试用。 project/plugin.sbt如下所示： 请指教。
-
War插件增加了名为providedCompile和providedRuntime的两个依赖配置.这两个配置有相同的作用域在编译或者运行时的配置,不同之处在于是否会将war文件归档.很重要的一点是它们都会提供配置传递.比如在任意的provided配置中添加了commons-httpclient:commons-httpclient:3.0,该依赖依赖于commons-codec,因为这个一个”pr
-
Java 插件给项目增加了许多关于依赖的配置, 如下所示, 这些配置被分配给许多任务, 比如 compileJava 和 test 等配置 表22.5.Java插件-依赖配置 名称 扩展 被使用时运行的任务 含义 compile - compileJava 编译时的依赖 runtime compile - 运行时的依赖 testCompile compile compileTestJava 编译测