前奏

我们上篇文章，跟大家说了下，怎么调试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

就是个文本文件啊，里面好像写了些似是而非的东西，不能看懂得多了，但是看得懂一点点。

这里呢，我提炼一下关键信息，其实有三点：

1. 接下来要把执行权交给谁？

   这个就是从main is org.apache.maven.cli.MavenCli from plexus.core这一行，org.apache.maven.cli.MavenCli就是接下来的框架核心代码的启动人

2. 主配置文件在哪里

   在maven安装目录的conf下，这里面有我们的settings.xml，这个大家都晓得了哈

3. 框架核心代码在哪里

   这就交给下面几位来指定了

   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 发布！