原文链接 译者：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，更先进的配置将被证实。