为什么Gradle或Maven没有依赖版本的锁定文件？

问题描述 投票：8回答：3

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

我的问题是：

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

  2. 在包管理器的依赖关系解决方案策略中允许版本范围与仅允许确切版本相比，其优缺点是什么？] >>

    3. 最近阅读有关NPM，Yarn，Paket，Cargo等软件包管理器的信息时，我已经引入了依赖性版本锁定文件的概念。我的理解是，它是一个列出...的文件。]

1。

Maven会not

有一种方法可以实现您的要求。即使您为直接依赖项设置了特定的版本（应该这样做），由于看似无关的更改，您的传递性依赖项也很容易被无意地更改。例如，在新库上添加依赖项可以为您提供现有传递性依赖项的旧版本。

您需要的是dependencyManagement部分，其中列出了所有直接和可传递的依赖关系。您仍将无法检测是否删除或添加了传递依赖项（例如NPM提供的功能）。缺少的问题是所有依赖项都不再位于dependencyManagement部分中。要检测这些变化，可以使用我编写的类似https://github.com/vandmo/dependency-lock-maven-plugin的东西。使用它还会使所有内容都没有在dependencyManagement部分中变得不那么重要，因为将检测到传递性依赖项中的更改。

我也建议在您的构建中使用https://maven.apache.org/enforcer/enforcer-rules/requireUpperBoundDeps.html，因为Maven选择树中关闭的传递依赖项的版本，而不是您期望的最高版本。

我已经看到许多由于开发人员意外更改传递依赖而导致的运行时问题。

TL; DR：您do

在Maven中需要锁定文件之类的东西，但是由于历史上的意识形态原因，它不存在。

2。

我不建议使用版本范围，因为它们会使您的构建不可复制。在传递依赖方面，它的行为也不像您所相信的那样。

Maven，SBT和Gradle都有您所描述的内容。它称为“使用已发布（或固定）版本”。与版本范围1.2.3或快照（[1.2.3,)）相比，发布的版本看起来像1.2.3-SNAPSHOT。

如果您所有的依赖项都使用发布的版本，您将实现您所描述的内容。

版本范围也是一种有效的版本形式，具体取决于您的用例，但是我通常会建议不要使用它们，除非它们用于父级POM -s，或者仅在活动开发期间使用。如果您确定不必继续更新第三方或父POM的固定版本，则可以确定版本范围，如果您确定各个工件绝对不会破坏您的工作（并且值得信赖）对我来说，版本范围确实会发生很多事情。当您想保证代码能够针对您最初设计和测试的内容进行构建和使用时，应使用固定版本。

如果您的pom.xml严格定义了依赖项的版本，则无需具有“锁定文件”之类的功能或类似的功能。

如果您阅读了有关依赖性管理的文档，将会发现确实如此：

gradle classes --update-locks org.apache.commons:commons-lang3,org.slf4j:slf4j-api

或者，您可以说“去更新我所有的部门”：
gradle dependencies --write-locks

如果您要研究自动化，指定分辨率策略也值得回顾：https://docs.gradle.org/current/userguide/dependency_resolution.html
java maven gradle package-managers dependency-resolution
3个回答
7
投票

1。

1
投票

Maven，SBT和Gradle都有您所描述的内容。它称为“使用已发布（或固定）版本”。与版本范围1.2.3或快照（[1.2.3,)）相比，发布的版本看起来像1.2.3-SNAPSHOT。

如果您所有的依赖项都使用发布的版本，您将实现您所描述的内容。

0
投票

Dependency locking是一项功能，在Gradle 5.0中已达到一定的成熟度：https://docs.gradle.org/current/userguide/dependency_locking.html

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.