renatoathaydes/jbuild:比Maven能更好地解决Java依赖冲突


依赖管理是一个困难的话题,比大多数开发人员可能意识到的要困难得多。
只要一切正常,您几乎不需要关注您当前使用的依赖项的哪个版本(但您当然应该),所以这是可以理解的。
但是,如果您想构建可靠的软件,同时在所有依赖项中跟上最新的安全补丁,这需要不断更新库并确保没有意外引入重大更改并且所有库保持相互兼容,那么您就是迎接挑战。

JBuild 是一个用于构建 Java 和其他基于 JVM 语言的项目的工具包,专注于依赖管理和应用程序的类路径验证。
它由一个简单的 CLI 组成,因此可以用作非常方便的命令行实用程序,但也可以用作 Java 库,允许 JVM 应用程序自己管理其他 Java 项目和依赖项。

不同于传统Maven或gradle,JBuild不是依赖版本号解决依赖冲突,而是在解决了依赖关系树之后,在不删除任何冲突的情况下,实际查看每个jar的字节码。
给定一个或多个入口点(包含应用程序主程序的罐子),它将遍历这些入口点中每个类的AST,寻找它所需要的引用,并尝试在候选classpaths中的其他罐子中找到它们,递归地,直到它能证明一组罐子能很好地一起工作,至少在类型级别(遗憾的是,检查语义是否正确将是一个难以解决的问题)。
详细分析

Maven/Gradle/Ant 不关心实际代码,所以到目前为止我们所看到的混乱依赖现状都没有改变。但是 JBuild 很在乎!
让我们检查依赖树是否显示冲突:

jbuild deps -t com.mycompany.app:my-app:1.1
Dependencies of com.mycompany.app:my-app:1.1 (incl. transitive):
  - scope compile
    * com.fourthcompany.app:fourth-app:1.0 [compile]
    * com.othercompany.app:other-app:1.1 [compile]
        * com.thirdcompany.app:third-app:1.1 [compile]
            * com.fourthcompany.app:fourth-app:1.1 [compile]
  The artifact com.fourthcompany.app:fourth-app is required with more than one version:
    * 1.1 (com.othercompany.app:other-app:1.1 -> com.thirdcompany.app:third-app:1.1 -> com.fourthcompany.app:fourth-app:1.1)
    * 1.0 (com.fourthcompany.app:fourth-app:1.0)
  4 compile dependencies listed
  - scope test
    * junit:junit:4.11 [test]
        * org.hamcrest:hamcrest-core:1.3 [compile]
  2 test dependencies listed
JBuild success in 289 ms!