前奏
我们上篇文章,跟大家说了下,怎么调试maven插件的代码,注意,是插件的代码。插件,是要让主框架来执行的,主框架是谁呢,就是maven core,可以称之为maven核心吧。
maven核心,类似于tomcat,而maven插件就类似于我们部署在tomcat中的webapp应用。估计有人觉得,这个类比有点生硬,不过我也是有我自己的依据的。
下面开始正文。
tomcat的类分散在哪几处
按照简单的模型来分,三处:
1、bin下边的启动类等
2、lib下的tomcat核心框架类
3、webapp的类
这个就不说了,就是大家的业务类。
maven和tomcat的相似之处
下边,我们看maven的jar包的分散情况。
1、启动类
在maven home的boot目录下
2、maven core
3、插件代码
分布在本地仓库中的目录中。
汇总一下,这两个框架,执行过程中需要用到的jar包,都分散在了三个地方。按照我们的理解,执行顺序是:
从启动类出发 --》 加载框架核心代码 --》 框架去加载插件/webapp代码来执行。
当然了,大家可以想想啊,换成你来写这个tomcat、maven,你怎么办?三种代码,三个地方,肯定要三个类加载器吧。第一个类加载器,只能加载到启动类那几个包;要去调用框架核心,是不是又得新建一个类加载器;框架核心,要去调用插件/webapp代码,又要新疆类加载器吧。
中间怎么衔接啊?
maven clean时,到底发生了什么(启动类阶段)
如果我们直接在命令行执行mvn clean,实际上是调用了 如下命令:
这个命令是啥呢,我之前工作多年的经验告诉我,这是个二进制,打开必须是一串乱码啊;然后之前对maven也没好奇心,没研究过,最近才知道,这他么是个shell/cmd。
原来是个java命令?? 果然啊,经验主义还是要不得,大意了大意了。
我这边是个windows电脑,实在不方便打印出来最终的执行命令,于是采用了一些迂回方式。
在我的F:\tools\apache-maven-3.8.1-bin\apache-maven-3.8.1\bin
目录下,打开git bash,用shell来执行:
大家可以看下,这里的classpath中的jar,就是我前文提到的,maven home的boot目录下的 jar,启动类,就是在这个jar里面。
这里,大家可以想想启动类的目标是啥,是要去加载框架核心。对于启动类来说,重点在于:框架类的代码在哪里呢?是靠默认约定吗,还是读一个什么配置文件。
答案就是配置文件。
可以看看上面的图里,有一条:
-Dclassworlds.conf=/f/tools/apache-maven-3.8.1-bin/apache-maven-3.8.1/bin/m2.conf
这个文件,我们打开看一下:
main is org.apache.maven.cli.MavenCli from plexus.core
set maven.conf default ${maven.home}/conf
[plexus.core]
load ${maven.conf}/logging
optionally ${maven.home}/lib/ext/*.jar
load ${maven.home}/lib/*.jar
就是个文本文件啊,里面好像写了些似是而非的东西,不能看懂得多了,但是看得懂一点点。
这里呢,我提炼一下关键信息,其实有三点:
接下来要把执行权交给谁?
这个就是从
main is org.apache.maven.cli.MavenCli from plexus.core
这一行,org.apache.maven.cli.MavenCli
就是接下来的框架核心代码的启动人主配置文件在哪里
在maven安装目录的conf下,这里面有我们的settings.xml,这个大家都晓得了哈
框架核心代码在哪里
这就交给下面几位来指定了
load ${maven.conf}/logging optionally ${maven.home}/lib/ext/*.jar load ${maven.home}/lib/*.jar
maven clean时,到底发生了什么(框架核心类阶段)
这个阶段,内容就太多了,${maven.home}/lib/*.jar
这足足十来个jar包,后面有的是时间说。
我们现在重要的是,把流程先梳理通,框架核心的目标,就是根据参数,找到对应的插件代码,加载进来,然后执行。
我们前面,传参就是clean,clean其实是代表了clean这个生命周期里的clean阶段,而clean阶段,绑定的插件就是:maven-clean-plugin
。
那这个插件的代码,去哪里找呢?这次,就是maven 约定优于配置的理念的体现了,没有采用配置文件,插件和我们的业务依赖一样,都放在本地仓库,本地仓库找不到,就去远程中央仓库下载。
我们这里,本地已经有了:
拿到jar后,就是创建一个专供该插件的类加载器,来加载这个插件的jar,以及插件依赖的jar。
插件依赖的jar,能在哪里看呢,在这个插件的描述文件里,描述文件就是下边这个,它描述了插件的方方面面,比如有哪些可以执行的goal、goal的参数是啥,当然,也包括了插件依赖的jar。
插件依赖如下:
maven clean时,到底发生了什么(插件被框架核心执行阶段)
框架是被执行的。为什么叫:被执行。就是,一切的掌控逻辑,都在框架核心中。
插件呢,是要按照规范来的,谁的规范,框架核心的规范,规范是啥,就是框架核心定的一个接口:
public interface Mojo {
// 插件逻辑写在这个里面
void execute() throws MojoExecutionException, MojoFailureException;
void setLog(Log var1);
Log getLog();
}
clean插件的实现逻辑:
框架核心做了啥,就是加载org.apache.maven.plugin.clean.CleanMojo
,然后强制向上转型成Mojo
,然后优雅地用多态来执行execute
方法,调用插件的实际逻辑即可。
maven上述运行过程中的几个类加载器实例赏析
我在插件里,睡了1000秒,然后执行 jmap -dump:live,format=b,file=heap16380.bin 16380
(16380是我maven这个java进程的pid)
把堆dump下来后,还是照例分析一把,看看堆里有哪些类加载器:
一共18个,还真不少。不过很多都是不用关心的,上图中,我们只关注三个:
1、启动时的加载器-AppClassloader
2、框架核心类加载器
如我们所见,确实都是 lib下的jar。
3、插件类加载器
如我们所见,去本地仓库加载了插件的jar。
总结
本来吧,我是想讲maven框架核心的调试环境搭建,结果,就来了个这,毕竟,不把这个说清楚,环境搭建感觉也说不清。。
环境搭建等下篇,see u,以上。
本文由博客一文多发平台 OpenWrite 发布!