1、本节定位
其实实际开发中几乎没有什么场景需要我们开发自定义 Maven 插件,所以本节只是通过这个角度帮助我们更好的理解插件的目标和生命周期阶段之间的关系。
2、插件开发
①创建工程
[略]
②设定打包方式
<packaging>maven-plugin</packaging>
其实实际开发中几乎没有什么场景需要我们开发自定义 Maven 插件,所以本节只是通过这个角度帮助我们更好的理解插件的目标和生命周期阶段之间的关系。
[略]
<packaging>maven-plugin</packaging>
这里我们可以对接 profile 这个单词中『侧面』这个含义:项目的每一个运行环境,相当于是项目整体的一个侧面。
小诀窍:使用迅雷下载比直接用浏览器下载快很多 https://download.sonatype.com/nexus/3/latest-unix.tar.gz
上传到 Linux 系统,解压后即可使用,不需要安装。但是需要注意:必须提前安装 JDK。
[root@x nexus-3.37.0-01]# ll
总用量 96
drwxr-xr-x. 3 root root 4096 2月 13 17:33 bin
drwxr-xr-x. 2 root root 4096 2月 13 17:33 deploy
drwxr-xr-x. 7 root root 4096 2月 13 17:33 etc
drwxr-xr-x. 5 root root 4096 2月 13 17:33 lib
-rw-r--r--. 1 root root 651 11月 20 01:40 NOTICE.txt
-rw-r--r--. 1 root root 17321 11月 20 01:40 OSS-LICENSE.txt
-rw-r--r--. 1 root root 41954 11月 20 01:40 PRO-LICENSE.txt
drwxr-xr-x. 3 root root 4096 2月 13 17:33 public
drwxr-xr-x. 3 root root 4096 2月 13 17:33 replicator
drwxr-xr-x. 23 root root 4096 2月 13 17:33 system
先给结论:编订依赖列表的程序员。初次设定一组依赖,因为尚未经过验证,所以确实有可能存在各种问题,需要做有针对性的调整。那么谁来做这件事呢?我们最不希望看到的就是:团队中每个程序员都需要自己去找依赖,即使是做同一个项目,每个模块也各加各的依赖,没有统一管理。那前人踩过的坑,后人还要再踩一遍。而且大家用的依赖有很多细节都不一样,版本更是五花八门,这就让事情变得更加复杂。 所以虽然初期需要根据项目开发和实际运行情况对依赖配置不断调整,最终确定一个各方面都 OK 的版本。但是一旦确定下来,放在父工程中做依赖管理,各个子模块各取所需,这样基本上就能很好的避免问题的扩散。 即使开发中遇到了新问题,也可以回到源头检查、调整 dependencyManagement 配置的列表——而不是每个模块都要改。所以学完这一节你应该就会对前面讲过的『继承』有了更深的理解。
『体系外 jar 包』这个名字是我起的,来源是这样——目前来说我们在 Maven 工程中用到的 jar 包都是通过 Maven 本身的机制导入进来的。 而实际开发中确实有可能用到一些 jar 包并非是用 Maven 的方式发布,那自然也没法通过 Maven 导入。 此时如果我们能够拿到该 jar 包的源码那还可以自己建一个 Maven 工程,自己打包。可是如果连源码都没有呢? 这方面的例子包括一些人脸识别用的 jar 包、海康视频监控 jar 包等等。
我们通过学 Maven 以前的方式创建一个 Java 工程,然后导出 jar 包即可用来测试。