Maven和Tomcat能有啥联系呢，都穿打补丁的衣服吗
前奏
我们上篇文章，跟大家说了下，怎么调试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: oolsapache-maven-3.8.1-binapache-maven-3.8.1in目录下，打开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，以上。