问题标签 [dependency-resolution]

我知道使用npm shrinkwrap有助于锁定依赖关系，以帮助保证应用程序的可复制构建。

我的问题是，如果您构建的是模块而不是应用程序怎么办？模块的每个版本都应该包含一个npm-shrinkwrap.json? 我查看了一些开源模块，但没有在它们的存储库中看到它们（例如：express、react、chai、async）。

我的理解是 npm (>=3) 通过整合兼容版本提供的好处。例如，如果 pkg-a 依赖于 lodash^4.0.0并且 pkg-b 依赖于 lodash ^4.3.5，它只会安装最新的 lodash 4 版本的一个副本。但是如果 pkg-a 和 pkg-b 都创建了 shrinkwraps，那么它们很可能不会对应于完全相同的 lodash 版本，并且需要安装该库的两个副本，即使它们是完全兼容的版本。

不包括收缩包装的缺点是库作者正在构建一个包，该包将被其他应用程序依赖，并且当它的任何依赖项（或依赖项的依赖项，递归地）发布破坏性更改时，该包可能随时损坏次要版本或补丁版本。并且在依赖项的依赖项中断的情况下，库作者除了发布收缩包装外，无能为力。

例如，如果我的库依赖于request，它依赖于hawk，并且 hawk 在补丁版本中发布了一个重大更改，那么即使锁定到 request 的确切版本也不会修复我的库——唯一的方法（到目前为止正如我所看到的）修复我的库是发布一个缩小鹰的确切版本的收缩包装。

这变得冗长，但我试图了解是否有更好的论据在 Node 模块中使用收缩包装而不是通过不使用它们来利用 npm 提供的好处。

我在 SBT 解决传递依赖项时遇到问题。

错误是：

Geospark正在使用jts2geojson https://github.com/bjornharrtell/jts2geojson/blob/master/pom.xmlwhich 在 version 中引用 jts 1.14，但这被排除在外，他​​们使用自定义工件作为替代品。它被称为JTSPlus仍然存在于com.vividsolutions名称空间中并提供一些附加方法，即上面缺少的方法。

最新版本geotools 17使用https://github.com/geotools/geotools/blob/master/pom.xml#L752-L754jts1.13

我需要从提供额外但必需功能的 geotools中替换com.vividsolution.jtsorg.datasyslab.jtsplus，我该如何实现？

在 Maven 中：

应该可以工作，但对于 SBT 使用

没有修复它。实际上，在使用dependencyGraph时，我可以看到SBT仍在将1.13版中的常规jts应用于整个项目。

如何修复依赖项以正确排除原始 JTS 版本？

我的 build.sbt 看起来像

与让 Maven 和 SBT 都使用本地 Artifactory-server类似，我想让 sbt 和 maven 使用本地 artifactory 服务器。对于 SBT，我面临一些问题：

添加https://repo.typesafe.com/typesafe/ivy-releases/作为 ivy 或 maven 项目并没有帮助。

Sbt 有以下设置

最近在阅读 NPM、Yarn、Paket、Cargo 等包管理器时，我被介绍了依赖版本锁定文件的概念。我的理解是，它是一个列出所有直接和传递依赖关系及其确切的文件的文件版本号，因此可以保证后续构建使用一组等效的依赖项。这似乎是一个理想的功能，因为许多包管理器已经或正在采用这个概念。

我的问题是：

1. 为什么 Maven 或 Gradle 不使用锁定文件？或者如果他们这样做了，为什么我没有看到呢？

2. 在包管理器的依赖解析策略中允许版本范围与只允许精确版本有什么优缺点？

Gradle 构建报告 html 显示Dependency Resolution每次运行我的总时间超过 30 秒，app无论我修改了多少东西。我觉得每次运行都要花这么长时间解决依赖关系是不合理的，因为项目的依赖关系甚至永远不会改变。

摇篮版本：2.10

安卓插件版本：2.1.0

最好不要更改版本。

部分报告：

顺便说一句：为什么debugAssemble任务包含一些任务或依赖项，例如releaseXXX？需要手动排除吗？

我有一个 Gradle 3.5 项目，在该项目中我依赖于一个工件：

“depProject”是一个 Maven 项目，在该项目的 pom 文件中，它依赖于另一个工件：

现在，当我对我的项目执行“gradle dependencies”时，它正确地表明我应该通过传递依赖解析获得 solrj 依赖，但它不尊重 4.4.0 版本声明，而是我的项目获得了对 5.5 版本的依赖.4.

这些行在依赖项报告中出现多次，始终相同。

为什么 Gradle 会自动“升级”我的依赖项？有没有办法让它停止，而不是直接依赖传递依赖，指定我想要的版本？

请注意，如果我通过以下方式排除项目中的 solrj 依赖项：

然后在生成的“gradle dependencies”调用中没有 solrj 依赖，因此在更高版本中没有其他地方依赖 solrj。

我无法发布整个 build.gradle，但我可以显示应用了哪些插件：

我正在尝试从具有用户名密码的自定义存储库中获取依赖项解析以在 Grails 2.2 中工作。

我尝试在 BuildConfig.groovy 中添加以下内容

但我得到错误

我尝试查看https://grails.github.io/grails2-doc/2.2.0/guide/single.html#dependencyRepositories但它没有告诉我更多信息。它确实说我需要将凭据放在 settings.groovy 中，但这绝对有必要吗？我尝试将凭据放入 mavenRepo 闭包中，但这不起作用。有任何想法吗？

Maven 可以-T <num_threads>选择。SBT有类似的东西吗？如何让它在并行线程中下载我的依赖项而不是按顺序执行？

我与传递依赖有冲突。覆盖、排除或强制没有帮助。我还能做些什么来将正确版本的库放入 jar 中？完整的代码是。找到https://github.com/geoHeil/gradle-dependency-resolution但它的主要部分如下所述。

问题描述

执行

禁用了 geomesa 依赖项（它引入了过时版本的 typesafe/lightbend 配置库）：

并执行 jar

输出

启用依赖项时：

它失败了

这与配置库的过时版本有关，如何解决类型安全配置上的 NoSuchMethodError？. 也通过以下方式确认：

如何将传递依赖项修复到我想要的 1.3.3 版本？

我的解决方案

试图设置：

并重新运行 jar 再次失败并出现同样的问题。

还有一个约束https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:dependency_constraints像：

或使用强制https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version像：

或喜欢：

没有给出正确的版本。

结果

所有变体都失败并出现相同的错误

怎么了？必须有一种方法可以强制使用所需的版本。

我有一个带有这个build.gradle文件的 android 模块：

并在 Gradle 同步过程中收到此错误：

无法解决：support-compat

我使用的依赖标识符完全符合https://developer.android.com/topic/libraries/support-library/packages#v4-compat（当我写这个问题时）。

有趣的是这个问题只针对版本27.1.1！我测试过的所有其他版本（、24.2.0甚至）都可以。26.0.027.0.027.1.0

此外，我从这个版本 ( 27.1.1) 测试的所有其他支持库都可以。这里是它们的列表：

截图：

app如果我在模块或模块中插入依赖项，没有区别library。

我的项目级build.gradle文件：

我的gradle-wrapper.properties文件：