Maven和gradle中的Gemfile.lock等效

时间:2014-11-19 12:28:59

标签: maven gradle

As Maven(客户端)和IvyResolver(Gradle使用)Bundler解决了在配置文件(Bundler的Gemfile)上声明的库依赖关系。然而,在此之后Bundler将依赖解析保存在Gemfile.lock上。它允许其他开发人员使用完全相同的库。

例如,Maven通过不明确的方式使用决定论者来解决依赖性解析中的冲突。例如,将版本指定为...

<version>1.0.1</version>

不保证将使用该版本。并将版本指定为...

<version>[1.0.0,2.0.0)</version>

几乎不能保证。

是的,我可以手动编写

列出的所有版本
mvn dependency:resolve

但是,有没有自动方法呢?

非常清楚:是否有与Maven或Gradle中的Gemfile.lock等效的内容?


Java开发人员,如果您不熟悉Gemfile.lock,请查看:

http://bundler.io/v1.3/rationale.html

我在下面复制的重要部分:

  

将您的代码检入版本控制

     

在开发应用程序一段时间后,请检查   应用程序与Gemfile和Gemfile.lock快照一起使用。现在,   您的存储库记录了所有gem的确切版本   您最后一次使用时确认该应用程序   工作。请记住,虽然你的Gemfile只列出了三个宝石   (具有不同程度的版本严格性),您的应用程序取决于   一旦你考虑到了所有的宝石,就会有数十种宝石   你所依赖的宝石的隐含要求。

     

这很重要:Gemfile.lock使您的应用程序成为一个   包含您自己的代码和最后运行的第三方代码   时间你肯定知道一切都有效。指定准确   您在Gemfile中依赖的第三方代码的版本   不提供相同的保证,因为宝石通常声明一个范围   其依赖项的版本。

     

下次在同一台机器上运行bundle install时,bundler会   看到它已经拥有你需要的所有依赖项,并跳过   安装过程。

&#34;你不对。 Maven可以保证版本&#34;

是的,没错。如果你在pom.xml中声明了一个版本,maven会使用它。但是,如果它是在父母pom中宣布的,那么这个保证就会消失。

  
    

依赖关系中介 - 确定在遇到多个版本的工件时将使用哪个版本的依赖关系。目前,Maven 2.0仅支持使用&#34;最近的定义&#34;这意味着它将在依赖树中使用与项目最接近的依赖项的版本。您可以通过在项目的POM中明确声明版本来保证版本。请注意,如果两个依赖项版本在依赖关系树中处于相同的深度,则直到Maven 2.0.8没有定义哪一个会赢,但是从Maven 2.0.9开始,它在声明中的顺序是:第一次宣言获胜。

         

&#34;最近的定义&#34;意味着所使用的版本将是依赖关系树中与项目最接近的版本,例如。如果A,B和C的依赖关系被定义为A - >; B - &gt; C - &gt; D 2.0和A - &gt; E - &gt; D 1.0,然后在构建A时将使用D 1.0,因为从A到D到E的路径更短。您可以在A中向D 2.0显式添加依赖项以强制使用D 2.0

  

哦,看起来这与DRY原则相反。

3 个答案:

答案 0 :(得分:5)

nebula.gradle-dependency-lock插件可以做到这一点。

PS:Gradle不再使用常春藤了(如果那是你对IvyResolver的意思)。

答案 1 :(得分:2)

锁定依赖关系的解决方案是使用<dependencyManagement> section of the current pom或其父级,并且永远不会在您的pom的<version>部分声明<dependencies>

您可以使用Pedanic Pom Enforcer plugin强制执行此行为(以便只有父项目可以声明依赖项版本)。您还可以使用enforcer plugin to completely ban all transitive dependencies或各种子集(我甚至不认为gradle或bundle具有此级别的可配置性)。有些人真的喜欢这种行为,因为你可以做到这一点,这样你就可以声明每一个依赖关系,让你认识到你的app / library 可能的臃肿/耦合。

是的,这不是DRY,因为你基本上必须两次声明包(一次在dependencyManagement,第二次没有版本在dependencies)。如果您决定禁止所有传递,情况会更糟。您可以使用imports (ie bom:bill of material pom files)和/或父poms缓解干旱问题。有些像我自己的公司有一个主父pom,每个项目都使用每个依赖项(因此在项目中锁定库的版本)。请记住父母或导入的pom也可以进行版本化!

至于宝石锁文件的行为,实际上并没有什么类似的东西......错误的是它的存在并不像KISS(据说我被Gem.lock严重烧伤而更喜欢maven / gradle方式......每个都有它的优点。您可以编写一个基于maven dependency plugin的插件(即将分析的依赖项转储到文件中)。

答案 2 :(得分:-3)

你在这里不正确。如果您明确说明

<version>1.0.1</version>
在您的pom中,保证此版本将用于可能使用不同版本的传递依赖项。