【曹工雜談】Maven底層容器Plexus Container的前世今生，一代芳華終落幕

三國夢迴發表於2021-09-12
MavenAI

Maven底層容器Plexus Container的前世今生，一代芳華終落幕

前言

說實話，我非常地糾結，大家平時只是用Maven，對於內部的實現其實也不關心，我現在非要拉著大家給大家講。這就有個問題，Maven的內部，還是相對沒那麼簡單的，也算是個不小的工程了。

核心功能，大家是清楚的，內部的執行流程，大家也大概猜的出來：

  1. 解析命令列引數
  2. 準備各種上下文，簡單的mvn clean就涉及到當前專案的後設資料pom.xml、settings.xml（主要是本地、遠端倉庫相關）；
  3. 根據mvn clean或者mvn compile，找到對應的生命週期（大家應該都知道maven的三個lifecycle吧）；然後看看要執行生命週期中的哪些階段，順序是啥（這個和打包方式也有關，jar/war時，打包元件就不同）；
  4. 順序執行生命週期中的每個階段的時候，去找到對應的繫結的外掛，然後執行外掛（執行外掛又包括：根據外掛座標，去本地倉庫/遠端倉庫找對應的artifact，以及解析artifact中的外掛後設資料，後設資料中會告訴你，支援傳哪些引數，引數型別是啥）
  5. 執行完成後，返回結果。

這麼一個不小的工程，想必，還是會有很多物件互相依賴的，在沒有依賴注入前，都是靠new，或者是工廠來緩解；我查了下歷史資料，maven的開發者在一篇文章中（https://blog.sonatype.com/2010/01/from-plexus-to-guice-1-why-guice/），提到：

We knew we needed some sort of component framework, some standard mechanism to instantiate plugins and configure them based on a set of configuration points

大概意思，他們也發現他們需要一個元件框架，一種標準化能夠例項化元件的機制，能夠基於一組配置來配置這些元件。

說明，早期的Maven開發者們，已經意識到了自己可能需要一個類似容器的東西，那，為啥沒有選用Spring呢？

下邊，讓我們來層層揭開歷史的面紗。

Maven初起步

查閱了Maven官網，發現Maven的第一個版本，竟然早在2002年。（http://jakarta.apache.org/site/news/news-2002.html）。

2003年，成為Apache頂級專案，2004年，釋出1.0版本。

另外一邊，我們熟知的，無人不知無人不曉的Spring呢，第一個版本是什麼時候呢？

The first version was written by Rod Johnson, who released the framework with the publication of his book Expert One-on-One J2EE Design and Development in October 2002.

這裡說，spring的第一個版本同樣釋出於2002年，是跟隨著Rod Johnson的書《Expert One-on-One J2EE Design and Development 》一起釋出的。也是在03年，使用Apache 2.0 License，釋出了一個版本；04年3月，釋出了一個生產用的版本。

所以，我們就可以理解，Maven的開發者在那篇2010年的文章裡寫的：

When we started the Maven project, dependency injection was still developing. Spring was just starting out and the Avalon project at Apache was really the only IoC framework around

簡單說，就是，當開始搞Maven的時候，依賴注入還在發展當中。Spring剛起步，Avalon專案，也僅僅只是一個ioc框架。

既然外部不成熟，他們的重心也不在這些依賴注入框架上面，所以他們就基於自己的需求，自己搞了一個適合Maven的，它就叫：Plexus。

Maven早期：做自己的IOC容器

Plexus專案

Plexus: 發音(ˈpleksəs)，a network of nerves or vessels in the body.

Plexus，中文意思，可能是神經網路或者血管網路，就因為血管是網狀的，像他麼網際網路一樣，所以被拿來當一個框架名了嗎，maybe。

這個專案（官網：https://codehaus-plexus.github.io），定位是做容器。官網不知道為啥，這會打不開，但是我發現一個記錄網際網路歷史的網站：https://web.archive.org/web/20150323083530/http://plexus.codehaus.org/index.html。

Plexus專案，基於其中的Plexus Container子專案，應用程式可以使用基於元件的程式設計方式，構建模組化的、可複用的元件。Plexus類似其他的IOC框架，如Spring，但它還額外提供了很多特性，如：元件生命週期管理、元件例項化策略、巢狀容器、元件配置、自動注入、元件依賴、各種依賴注入方式（如構造器注入、setter注入、欄位注入）。

總的來說，我個人感覺，這些特性，Spring好像也有啊，哈哈。

Plexus 下元件

Plexus這麼一個專案，當然不止容器，大概有如下幾個：

  • Plexus Classworlds，類載入器框架，Maven至今還在用，個人感覺也挺不錯，推薦學習學習；

  • Plexus Container，IOC容器，Maven 1.x/2.x在用，3.0版本後，Maven自身也沒有再使用了

  • Plexus Components

    Maven的工作就是和各種檔案、目錄打交道，這期間，會沉澱出來很多公用元件:

    1. IO相關的，Plexus IO Components，它的maven座標：
    <!-- https://mvnrepository.com/artifact/org.codehaus.plexus/plexus-io -->
<dependency>
    <groupId>org.codehaus.plexus</groupId>
    <artifactId>plexus-io</artifactId>
    <version>3.2.0</version>
</dependency>

    1. 歸檔相關的，Plexus Archiver Component，maven座標：

      <!-- https://mvnrepository.com/artifact/org.codehaus.plexus/plexus-archiver -->
<dependency>
    <groupId>org.codehaus.plexus</groupId>
    <artifactId>plexus-archiver</artifactId>
    <version>4.2.5</version>
</dependency>

    2. cli相關，Plexus CLI

    3. 編譯相關，Plexus Compiler

    4. Digest/Hashcode相關，Plexus Digest / Hashcode Components

    5. 國際化相關，i18n

    還有些其他的，我懶得列舉了，大家自己看吧，https://web.archive.org/web/20150225072024/http://plexus.codehaus.org/plexus-components/

  • Plexus Maven Plugin，用來支援Maven外掛

  • Plexus Utils，工具類，至今仍在用

Plexus元件的現狀

開啟我本機的maven安裝目錄的lib，發現plexus相關的，僅剩少數幾個了，如，下圖的幾個工具：

還有下圖的啟動類：

當初說好的IOC容器，結果Maven怎麼自己也不用了呢？我們來看看這個容器相關的元件吧。

容器相關的，一共4個maven元件。

這裡面，plexus-component-annotations我們剛看到，還在用，他是幹嘛的呢，就是類似於Spring裡面的註解，比如@Service/@Controller這種。

而plexus-component-metadata，是一個maven外掛，用來生成元件的xml，有點像我們的spring的xml時代，這個工程呢，就可以分析我們程式碼，幫我們生成spring的bean.xml這種，就不需要手動配置依賴了。

這裡面，真正的IOC容器實現，就是：plexus-container-default。

該元件，可以說是Maven的結髮妻子，陪伴了Maven的青年時期，我們看看這個元件是什麼時候第一次登場的。

下邊是它1.0版本的座標：

<!-- https://mvnrepository.com/artifact/plexus/plexus-container-default -->
<dependency>
    <groupId>plexus</groupId>
    <artifactId>plexus-container-default</artifactId>
    <version>1.0-alpha-1</version>
</dependency>

時間是2005年。

而maven什麼時候開始使用該容器呢，我沒有查到maven 1.x版本的pom依賴，但是在2.0.alpha版本，已經看到了該容器的身影：

此時，是2006年。

僅僅幾年後，在maven 3.0的版本中，已經不再有plexus ioc容器的身影，卻來了一個不速之客。

在開始說不速之客之前，我們還是要問問，plexus ioc容器，為啥就不行了呢？對這個歷史感興趣的，可以直接看：

https://blog.sonatype.com/2010/01/from-plexus-to-guice-1-why-guice/

為什麼呢？因為時代變了，此時，Spring已經開始成為事實上的IOC容器標準，不過，雖然Spring在應用開發領域，所向披靡，但是在各種框架中，框架開發者們還是覺得Spring太重了，一下就要引入好幾個jar包，實在是過於臃腫。因此，google 在2007年的時候，就推出了一個輕量級的依賴注入框架，叫google guice。

此時，經過多年的迭代，在2010年前後，guice已經比較成熟了，在google內部也而得到了廣泛應用，且依賴注入這個領域，也在持續不斷地發展中，比如java官方定義了相關的標準api。

而此時，Maven的開發者們已經難以同時維護Plexus IOC容器（比如適配java官方新出標準，和周邊Spring相容等等各類工作），因此，Maven決定，為了節省精力，Maven將不再基於Plexus IOC容器，而是使用Guice，以後就只管用了，而guice的維護升級，自然有Guice的開源團隊去跟進。

說了那麼多，為了紀念Plexus Container的落幕，我們還是來看看，這個IOC元件到底怎麼用的吧？

Plexus IOC容器初使用

例子也是來自於官網，我根據文件，整理成了一個maven module。大家可以拉程式碼下來。

https://gitee.com/ckl111/maven-3.8.1-source-learn/tree/master/my-test-modules/plexus-ioc-container-test

1.像所有的IOC容器一樣，定義一個介面和實現類

public interface Cheese
{
    /** The Plexus role identifier. */
    String ROLE = Cheese.class.getName();

    /**
     * Slices the cheese for apportioning onto crackers.
     * @param slices the number of slices
     */
    void slice( int slices );

    /**
     * Get the description of the aroma of the cheese.
     * @return the aroma
     */
    String getAroma();
}

public class ParmesanCheese
        implements Cheese
{
    public void slice( int slices )
    {
        throw new UnsupportedOperationException( "No can do" );
    }

    public String getAroma()
    {
        return "strong";
    }
}

就像spring的xml時代一樣，定義元件的依賴關係

注意一下，這裡的元件配置中，有三個元素：

  • role，此處放：介面名稱
  • role-hint，此處放：實現類的qualifier，類似spring中，一個介面多個實現類，我們就會給這多個實現類，定義一個顯示的名字，@Qualifier
  • implementation，實現類的類名。

ok，這就定義好了一個元件。

我們開始測試。

從容器中獲取元件

public class App {
    public static void main(String args[]) throws Exception
    {
        // 1  定義一個容器，容器會去載入classpath下的META-INF/Plexus/component.xml中的元件
        PlexusContainer container= new DefaultPlexusContainer();
        // 2 獲取元件，完成依賴注入等工作
        Cheese cheese = (Cheese) container.lookup( Cheese.ROLE, "parmesan" );
        // 3 使用元件
        System.out.println( "Parmesan is " + cheese.getAroma() );
        // 4 銷燬容器
        container.dispose();
    }
}

其他用法

如果這個元件，依賴其他元件，怎麼辦呢，怎麼注入呢？

我在maven原始碼工程裡看到這樣的元件配置，想必，就是像如下這樣配置。

<?xml version="1.0"?>
<component-set>
  <components>
    <component>
      <role>org.apache.maven.profiles.activation.ProfileActivator</role>
      <role-hint>faulty</role-hint>
      <implementation>org.ext.App</implementation>
      <requirements>
        <requirement>
          <role>org.apache.maven.artifact.ArtifactResolver</role>
          <field-name>artifactResolver</field-name>
        </requirement>
      </requirements>
    </component>
  </components>
</component-set>

迴圈依賴怎麼辦呢？放心，人家也是可以解決的，這裡就不截圖了。

總結

一個元件，寫出來，竟然感覺就像是也有感情一樣，也是有點意思。不過不管怎麼說，Plexus Container在陪伴Maven度過了整個2.x版本後，終將落下帷幕。

接下來，是Guice的時代，而現在，十多年後的2021年，Guice依然穩定地支撐著Maven。Guice足夠優秀，在此之前，我竟然幾乎沒什麼瞭解，Guice在哪些地方有應用呢，簡單列舉幾個：

  • google內部
  • scalatest
  • TestNG
  • Caffeine Cache
  • Spring Security Config
  • elastic search
  • jenkins

以及一些其他的我不太熟悉的技術，大家可以檢視：

https://mvnrepository.com/artifact/com.google.inject/guice/usages

相關文章