原文連結 譯者：carvendy

配置預設Mojo擴充套件

在這麼多例子中，你需要配置一個外掛，這裡有兩個選項生效：外掛級別配置配置和執行級別配置。外掛級別配置是很多公共方法配置的外掛，將用於命令列，是定義作為預設的生命週期，或者使用一個公共配置在所有呼叫。事實上，為了指引從命令列呼叫，外掛級別配置已經是歷史上唯一的選擇。

在另一方面，例子中一些先進的構建程序需要一些mojos的執行同樣的mojos，也有不同一些來自於單個外掛使用了不同的配置，執行級別配置是很常用的。這些例子通常涉及的外掛是介紹作為一部分的標準構建程序，但是這裡目前不是在預設生命週期的特別打包。在這些用例，通常配置分享不同執行，是依然指定在外掛級別的配置。

無論如何，這兩個選擇離開了一些主要配置用例：

# Mojo從命令列執行和期間構建，當CLI驅動涉及到需要它自己的配置。

# Mojo執行是跳躍到生命週期作為預設匹配特別的打包，特別在例子中相同的mojo需要加入秒級執行的不同配置。

# mojo組從同樣的外掛，是繫結到生命週期作為一部分預設匹配而為了特殊的打包，但是需要分開配置。

原來，執行id的預設值——字面上設定預設是在pom模型裡——意味著提供一些功能。不幸的是，這解決方案是未經上面的用例測試確認的；他們掉進裂縫在測試。現在，在Maven 2.2.0版本（或者更新一點，Maven 3.0），他們使用用例最終是可以解決的。

隱含執行預設executionIds

當你考慮到事實上，前述配置使用用例是為了mojos不用再POM中明確，這很容易理解是參考它們隱含的執行。但是如果它們隱含，Maven怎麼能讓使用者提供配置給他們呢？這個請求我們實現了相當簡單和低階技術含量，但是應該有更多充足的處理先進的用例。在Maven 2.2.0中，每一個mojo呼叫來自於命令列將有一個default-cli分配的執行id，這將使一個執行配置和使用這個預設執行ID POM。同樣，每一個mojo繫結構建生命週期通過預設生命週期匹配而為了指定的POM打包，將有==default-<goalName> ==的執行ID分配給他，來允許獨立配置每一個預設的執行。

例子：命令列轉化為 assembly plugin呼叫

考慮到用例中使用者想執行assembly:assemblymojo指到命令列，但是已經有配置為了assembly:singlemojo在執行主構建生命週期。自從這些配置需要不同選擇，使用者不能使用外掛級別配置選項來指定公共元素。

在這些用例，assembly-plugin外掛可能像這樣：

<plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <configuration>
        <tarLongFileMode>gnu</tarLongFileMode>    
      </configuration>
      <executions>
        <execution>
          <id>build-distros</id>
          <phase>package</phase>
          <goals>
            <goal>single</goal>
          </goals>
          <configuration>
            <descriptors>
              <descriptor>src/main/assembly/bin.xml</descriptor>
              <descriptor>src/main/assembly/src.xml</descriptor>
            </descriptors>
          </configuration>
        </execution>
        <execution>
          <id>default-cli</id>
          <configuration>
            <descriptorRefs>
              <descriptorRef>jar-with-dependencies</descriptorRef>
              <descriptorRef>project</descriptorRef>
            </descriptorRefs>
          </configuration>
        </execution>
      </executions>
    </plugin>

在上面的這些例子，你可以看到一些有趣的事情。首先，主構建構建程序將呼叫assembly:singlemojo在package構建週期，和生產二進位制和原始碼分佈工件使用自定義的裝配描述符，包含在專案中。第二，所有裝配外掛呼叫應該使用tarLongFileMode gnu的策略。最後，當裝配外掛是呼叫是從命令列，這是將構建標準的jar-with-dependencies 和project而為了專案，和忽略在src/main/assembly指定裝配的。

現在，注意在不同的兩個執行快引用裝配描述符。一個使用自定義描述符通過descriptors選項，和其他使用標準描述符通過descriptorRefs。這些兩個選項不能重寫其他的，所以這是不可能安裝到一個選項——說，descriptorRefs——在外掛級別配置塊（為了提供CLI授權給它，作為Maven需要的歷史版本），然後有build-distros呼叫使用在描述符中的自定義描述符覆蓋它。這些配置在Maven 2.0以前是不可能的。

例子：配置compile來執行兩次

在指令碼中，使用者想執行compile:compile指令兩次為了打包專案。主要原因是這是提供給一個進入到應用程式，這將警告使用者如果他使用比java1.5更老的，將會優雅地退出。沒有進入點，使用者將面對在事件中的堆疊，他嘗試執行應用在1.4或者更老的JRE中。

因此，使用者需要編譯他自己的程式目標是1.5的規範，然後編譯其他部分(入口要點)來標記倒更老的說明書。。。說1.3吧。首先使用執行原始碼和目標的值是1.5，和排除選項為了避免編譯程式的重要點。其次，將通過重新說明原始碼和目標的值是1.3，基本上顛倒原來的排除部分為一個包含部分，以便只編譯入口點類。

結果配置可能像這樣：

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <configuration>
    <source>1.5</source>
    <target>1.5</target>
  </configuration>
  <executions>
    <execution>
      <id>default-compile</id>
      <configuration>
        <excludes>
          <exclude>**/cli/*</exclude>
        </excludes>
      </configuration>
    </execution>
    <execution>
      <id>build-java14-cli</id>
      <phase>compile</phase>
      <goals>
        <goal>compile</goal>
      </goals>
      <configuration>
        <source>1.3</source>
        <target>1.3</target>
        <includes>
          <include>**/cli/*</include>
        </includes>
      </configuration>
    </execution>
  </executions>
</plugin>

關於上面的編譯外掛配置，這裡有三個重要的事情要注意的：

• 預設原始碼和目標相容性級別的Java 1.5.這意味著編譯生成的二進位制檔案的程式碼庫和測試程式碼庫來自於Java 1.5，除此之外被拒絕處理。
• 預設通過compile命令將被==**/cli/*路徑規則排除，但是將編譯任何在src/main/java==下的東西，執行與Java 1.5。
• 第二個預設compile命令- 在執行中被叫做build-java140-cli-重設原始碼和目標為1.3，並從首先通過的中顛倒排除規則。這意味著第二次期間，編譯器將產生1.4目標二進位制類來匹配==**cli*==路徑。

注意： 先前的Maven 2.2.0中，這是有很多不同的-如果沒有不可能——來編譯不同的子路徑使用與你專案的程式碼庫來標記不同java版本。

例子：分別配置compile和 testCompile命令

最後，構建我們使用的編譯器外掛來處理不同的用例，考慮到這些用例在使用者標記為Java 1.4規範作為執行平臺。無論如何，他依然希望便利和優勢地作為一個出名單元測試框架例如 TestNG.這強制使用者配置compile命令使用原始碼和目標的值-明確為1.4-和testCompile命令使用其他（1.5）

最後編譯外掛的配置可能如下：

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <executions>
    <execution>
      <id>default-compile</id>
      <configuration>
        <source>1.3</source>
        <target>1.3</target>
      </configuration>
    </execution>
    <execution>
      <id>default-testCompile</id>
      <configuration>
        <source>1.5</source>
        <target>1.5</target>
      </configuration>
    </execution>
  </executions>
</plugin>

這例子相當簡單和直接。首先，default-compile執行集合的原始碼和目標值為1.3來允許更老的Java 版本執行。然而，default-compile執行重置了的原始碼和目標值為1.5，可以在專案使用類似於TestNG工具一樣使用註解。

順帶地，這可能是有助於指出上面例子是有一些不自然的；編外掛預設標記為1.3，所以只能配置真正需要的default-compile執行。default-compile執行重新指定預設外掛。唯一一次可能有用的是當父級POM定義了一個外掛級別給原始碼和目標，這將會改變這些不同的編譯器執行。這例子意味著說明了需要分開配置不同的預設週期的命令在Maven 2.2.0中。

還有，上面配置將不可能使用更老的Maven版本。開始於2.2.0，更先進的配置將被證實。