即将取代Maven和Gradle的新一代更强更快的构建工具(至尊典藏版)

469 阅读6分钟

前言 大家好,我是程序缘--幻羽,我又来了!!

Maven和Gradle都是我们程序猿们日常开发必不可少的构建工具。

Apache Maven是一个(特别是Java编程)项目管理及自动构建工具,由Apache软件基金会所提供。基于项目对象模型(缩写:POM)概念,Maven利用一个中央信息片断能管理一个项目的构建、报告和文档等步骤。

它包含了一个项目对象模型 (Project Object Model),一组标准集合,一个项目生命周期(Project Lifecycle),一个依赖管理系统(Dependency Management System),和用来运行定义在生命周期阶段(phase)中插件(plugin)目标(goal)的逻辑。当你使用Maven的时候,你用一个明确定义的项目对象模型来描述你的项目,然后Maven可以应用横切的逻辑,这些逻辑来自一组共享的(或者自定义的)插件。

Maven 有一个生命周期,当你运行 mvn install 的时候被调用。这条命令告诉 Maven 执行一系列的有序的步骤,直到到达你指定的生命周期。遍历生命周期旅途中的一个影响就是,Maven 运行了许多默认的插件目标,这些目标完成了像编译和创建一个 JAR 文件这样的工作。

Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建开源工具。它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置,也增加了基于Kotlin语言的kotlin-based DSL,抛弃了基于XML的各种繁琐配置。是一款通用灵活的构建工具,支持maven, Ivy仓库,支持传递性依赖管理,而不需要远程仓库或者是pom.xml和ivy.xml配置文件,基于Groovy,build脚本使用Groovy编写。

gradle和maven都可以作为java程序的构建工具,但两者还是有很大的不同之处的:1.可扩展性,gradle比较灵活,maven的灵活性就差一些,但是maven的项目比较容易看懂,并且上手简单。2.性能比较,gradle比maven运行得快。gradle无论是在可扩展性还是在性能方面都优于maven。

相信作为Java开发者的你早已经受够了maven的编译缓慢,但是又由于历史包袱、使用习惯等问题暂时切换不了其他更快的构建工具,这里笔者将给你介绍一款更快的maven——maven-mvnd。

一、介绍

maven-mvnd是Apache Maven团队借鉴了Gradle和Takari后衍生出的更快的构建工具。mvnd内嵌了Maven,也正是因为这个原因我们可以无缝地将Maven切换为mvnd(也不需要单独安装Maven)。

在设计上,在mvnd中会生成一个或多个的守护进程来服务构建请求以此来达到并行构建的效果。另外在VM的选择上,mvnd使用了GraalVM来代替传统的JVM,与之相比GraalVM启动速度更快,占用的内存更少。

根据文档描述,与传统的Maven相比mvnd具有以下优势:

  1. 运行构建的JVM不需要为每个构建重新启动。
  2. Maven插件类的类加载器缓存在多个构建中,插件jars只会被读取和解析一次。
  3. JVM中JIT生成的本机代码会被保留。与Maven相比,JIT编译花费的时间更少。在重复构建期间,JIT优化的代码立即可用。这不仅适用于来自Maven插件和Maven内核的代码,也适用于来自JDK本身的所有代码。

默认情况下,mvnd使用多个CPU内核并行构建模块。使用的内核数由公式Math.max(Runtime.getRuntime().availableProcessors() - 1, 1)给出。如果您的源代码树不支持并行构建,请在命令行上传递-T1以使您的构建串行。

同时官方给出了24核机器上运行的动态图:

图片

二、安装

对于mvnd的安装,官方文档给了十分详细的教程,建议先行阅读:github.com/apache/mave…

笔者是通过Homebrew进行安装的,实践证明macOS m1安装使用是没有问题的。不过需要注意的是通过此种方式安装的mvnd版本为0.7.1,而经过在ubuntu和macOS m1上进行测试发现此版本并不支持JDK8(可能仅是笔者电脑问题),而通过官方例子所示的JDK11确是没问题。在JDK8运行mvnd命令会产生以下错误:

~ % mvnd -v
ErrorA JNI error has occurredplease check your installation and try again
Exception in thread "mainjava.lang.UnsupportedClassVersionErrororg/mvndaemon/mvnd/client/DefaultClient has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)

预估应该是这种方式下载的执行文件是通过高版本的JDK编译的,在低版本上运行因为缺少某些方法或特性所以运行不了。在一筹莫展之际,笔者从maven-mvnd的最新版本的更新说明上发现一个Closed issues:Different java versions for mvnd and maven #512,在该问题上作者提供了一种解决方案就是将JAVA_HOME所指定的版本设置为JDK11,并且在运行mvnd命令时加上参数-Dmaven.compiler.release=8,即

mvnd -Dmaven.compiler.release=8 compile

通过这种方式即能生成出JDK8所对应的编译代码。

对于issue #512中作者回应mvnd的最低支持版本是JDK8,但是笔者从0.5.2开始尝试还是报同样的错...或许是笔者电脑存在一定的问题,因为我看到其他人在贴出的结果图显示JDK8下最新版本也是能够安装并使用的。另外如果还是不行的话也许我们能够通过手动编译源码来生成可执行文件,具体步骤在官方readme上已经给出相应的步骤。

三、使用

在使用上与Maven的用法是完全相同的,只需将命令mvn改为mvnd即可。

而在笔者本机的实测中,与传统的Maven相比,通过mvnd的构建所耗费的时间是原来的1/2。

四、总结

本文笔者分别从maven-mvnd的介绍、安装、使用及其出现的一些异常情况展开陈述,如果读者想知道更多细节可阅读官方文档。

而也许强化后的Maven依然比不过Gradle,但是在历史包袱、使用习惯等背景下Maven的这次强化还是很香的。

原文链接:blog.csdn.net/weixin_4832…