《Maven官方文档》配置默认Mojo扩展

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

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 《Maven官方文档》配置默认Mojo扩展

魔术师Carvendy

魔术师Carvendy

尘世间一小小Javaer ,喜欢coding和思考。
魔术师Carvendy
FavoriteLoading添加本文到我的收藏
  • Trackback are closed
  • Comments (0)
  1. No comments yet.

You must be logged in to post a comment.

return top