【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗

前奏

我们上篇文章,跟大家说了下,怎么调试maven插件的代码,注意,是插件的代码。插件,是要让主框架来执行的,主框架是谁呢,就是maven core,可以称之为maven核心吧。

maven核心,类似于tomcat,而maven插件就类似于我们部署在tomcat中的webapp应用。估计有人觉得,这个类比有点生硬,不过我也是有我自己的依据的。

下面开始正文。

tomcat的类分散在哪几处

按照简单的模型来分,三处:

1、bin下边的启动类等

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第1张图片

2、lib下的tomcat核心框架类

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第2张图片

3、webapp的类

这个就不说了,就是大家的业务类。

maven和tomcat的相似之处

下边,我们看maven的jar包的分散情况。

1、启动类

在maven home的boot目录下

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第3张图片

2、maven core

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第4张图片

3、插件代码

分布在本地仓库中的目录中。

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第5张图片

汇总一下,这两个框架,执行过程中需要用到的jar包,都分散在了三个地方。按照我们的理解,执行顺序是:

从启动类出发 --》 加载框架核心代码 --》 框架去加载插件/webapp代码来执行。

当然了,大家可以想想啊,换成你来写这个tomcat、maven,你怎么办?三种代码,三个地方,肯定要三个类加载器吧。第一个类加载器,只能加载到启动类那几个包;要去调用框架核心,是不是又得新建一个类加载器;框架核心,要去调用插件/webapp代码,又要新疆类加载器吧。

中间怎么衔接啊?

maven clean时,到底发生了什么(启动类阶段)

如果我们直接在命令行执行mvn clean,实际上是调用了 如下命令:

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第6张图片

这个命令是啥呢,我之前工作多年的经验告诉我,这是个二进制,打开必须是一串乱码啊;然后之前对maven也没好奇心,没研究过,最近才知道,这他么是个shell/cmd。

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第7张图片

原来是个java命令?? 果然啊,经验主义还是要不得,大意了大意了。

我这边是个windows电脑,实在不方便打印出来最终的执行命令,于是采用了一些迂回方式。

在我的F:\tools\apache-maven-3.8.1-bin\apache-maven-3.8.1\bin目录下,打开git bash,用shell来执行:

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第8张图片

大家可以看下,这里的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 约定优于配置的理念的体现了,没有采用配置文件,插件和我们的业务依赖一样,都放在本地仓库,本地仓库找不到,就去远程中央仓库下载。

我们这里,本地已经有了:

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第9张图片

拿到jar后,就是创建一个专供该插件的类加载器,来加载这个插件的jar,以及插件依赖的jar。

插件依赖的jar,能在哪里看呢,在这个插件的描述文件里,描述文件就是下边这个,它描述了插件的方方面面,比如有哪些可以执行的goal、goal的参数是啥,当然,也包括了插件依赖的jar。

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第10张图片

插件依赖如下:

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第11张图片

maven clean时,到底发生了什么(插件被框架核心执行阶段)

框架是被执行的。为什么叫:被执行。就是,一切的掌控逻辑,都在框架核心中。

插件呢,是要按照规范来的,谁的规范,框架核心的规范,规范是啥,就是框架核心定的一个接口:

public interface Mojo {
    // 插件逻辑写在这个里面
    void execute() throws MojoExecutionException, MojoFailureException;

    void setLog(Log var1);

    Log getLog();
}

clean插件的实现逻辑:

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第12张图片

框架核心做了啥,就是加载org.apache.maven.plugin.clean.CleanMojo,然后强制向上转型成Mojo,然后优雅地用多态来执行execute方法,调用插件的实际逻辑即可。

maven上述运行过程中的几个类加载器实例赏析

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第13张图片

我在插件里,睡了1000秒,然后执行 jmap -dump:live,format=b,file=heap16380.bin 16380(16380是我maven这个java进程的pid)

把堆dump下来后,还是照例分析一把,看看堆里有哪些类加载器:

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第14张图片

一共18个,还真不少。不过很多都是不用关心的,上图中,我们只关注三个:

1、启动时的加载器-AppClassloader

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第15张图片

2、框架核心类加载器

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第16张图片

如我们所见,确实都是 lib下的jar。

3、插件类加载器

【曹工杂谈】Maven和Tomcat能有啥联系呢,都穿打补丁的衣服吗_第17张图片

如我们所见,去本地仓库加载了插件的jar。

总结

本来吧,我是想讲maven框架核心的调试环境搭建,结果,就来了个这,毕竟,不把这个说清楚,环境搭建感觉也说不清。。

环境搭建等下篇,see u,以上。

本文由博客一文多发平台 OpenWrite 发布!

你可能感兴趣的