• maven笔记


    默认中央仓库:
    http://repo1.maven.org/maven2
    https://repo.maven.apache.org/maven2


    -DskipTests=true 不执行测试用例,但编译测试
    -Dmaven.test.skip=true 不执行测试用例,也不编译测试用例类


    生命周期
    clean 清理项目
    default 构建项目
    site 生成项目站点文档

    生命周期对应的阶段
    clean生命周期
    pre-clean 执行一些清理前需要完成的工作
    clean 清理上一次构建生成的文件
    post-clean

    default生命周期
    validate 校验项目是否正确,检查必要信息是否可用
    initialize 构建状态初始化(比如,设置属性或生成目录)
    generate-source 生成编译中包含的源代码
    process-source 处理源代码(如过滤一些值)
    generate-resources 生成打包包含的资源文件
    process-resources 复制并处理资源到目标目录,准备打包
    compile 编译项目源代码
    process-classes 后处理编译生成的文件,例如:对class文件进行字节码增强
    generate-test-sources 生成编译中包含的测试源码
    process-test-sources 处理测试源代码,例如:过滤一些值
    generate-test-resources 创建测试用的资源文件
    process-test-resources 复制并处理资源到目标测试目录
    test-compile 编译测试源码放入测试目标文件夹中
    process-test-classes 后处理测试编译生成的文件,例如:对class文件进行字节码增强,对Maven 2.0.5及以上有效
    test 使用单元测试框架运行测试。测试代码不会被打包或者部署。
    prepare-package 执行必要的操作,在真正打包前准备一个包。这通常会产生一个未打包、处理过版本。(Maven 2.1及以上)
    package 接受编译好的代码,打包成可发布的格式,如:JAR
    pre-integration-test 在集成测试执行前进行些必要的操作。这也许会涉及相关的东西,例如安装必须的环境。
    integration-test 处理并将包文件部署到集成测试运行的环境
    post-integration-test 集成测试执行之后进行的必要操作。这可能包含了清理环境操作。
    verify 运行一些校验去验证包是否有效,是否符合质量标准。
    install 安装包到本地仓库,供本地其他项目依赖使用
    deploy 将最终的包复制到远程仓库,供其他开发人员和Maven项目使用

    site生命周期
    pre-site 执行一些在生成站点之前需要完成的工作
    site 生成项目站点文档
    post-site 执行一些在生成站点之后需要完成的工作
    site-deploy 将生成的站点文件发布到远程服务器上


    插件目标(Plugin Goal)

    插件能够为Maven提供不同的功能,而一个插件可能包含多个插件目标。比如,如下是插件 maven-dependency-plugin 包含的三个插件目标:
    插件目标 作用
    dependency:analyze 分析项目依赖
    dependency:tree 列出项目依赖树
    dependency:list 列出项目所有已解析的依赖
    命令中使用冒号(:)分隔插件和插件目标,比如compiler:compile表示 maven-compiler-plugin 插件的 compile 目标。

    插件绑定(Plugin Binding)
    前面说过,Maven只是定义了抽象的生命周期,生命周期阶段具体执行的操作是由其绑定的插件目标实现的。也就是说插件目标有一下两种方式被执行:
    通过绑定到生命周期阶段,而在生命周期阶段执行时被调用
    通过直接调用的方式(也就是“plugin:goal”的方式)在生命周期阶段外执行
    NOTE:一个插件目标可以绑定到多个生命周期阶段,一个生命周期阶段也能绑定多个插件。一个生命周期阶段绑定多个插件目标的情况,其执行顺序是按照POM文件中插件目标定义的顺序。

    默认插件绑定

    我们怎样才能够绑定插件目标到生命周期的阶段呢?两种方式:

    Maven内置默认绑定
    在POM文件中自定义绑定
    对于default生命周期,Maven会根据不同的packaging,绑定不同的插件目标。

    Clean 生命周期绑定

    生命周期 插件目标
    clean clean:clean
    Default 生命周期绑定 - Packaging ejb/ejb3/jar/par/rar/war

    生命周期 插件目标
    process-resources resources:resources
    compile compiler:compile
    process-test-resources resources:testResources
    test-compile compiler:testCompile
    test surefire:test
    package ejb:ejb或ejb3:ejb3或jar:jar或par:par或rar:rar或war:war
    install install:install
    deploy deploy:deploy
    Site 生命周期绑定

    生命周期 插件目标
    site site:site
    site-deploy site:deploy
    其他默认的插件目标绑定请参考Maven官方文档。

    自定义绑定

    自定义绑定可将一个插件目标绑定到任意构建生命周期阶段上。要实现自定义绑定,需要在project > plugins > plugin中声明。

    <project>
    ...
    <build>
    <plugins>
    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-source-plugin</artifactId>
    <version>2.1.1</version>
    <executions>
    <execution>
    <id>attach-sources</id>
    <phase>verify</phase>
    <goals>
    <goal>jar-no-fork</goal>
    </goals>
    </execution>
    </executions>
    </plugin>
    </plugins>
    </build>
    ...
    </project>

    以上示例中,声明了maven-source-plugin(使用groupId、artifactId、version指定)。然后在<executions>元素下指定多个任务<execution>,通过指定多个<execution>,就可以把相同插件的目标绑定到不同的生命周期阶段。<id>指定任务名称(在一个插件中必须唯一),<phase>指定到的生命周期阶段,<goal>指定插件目标。

    如果没有指定<phase>,那么就会绑定到插件默认的生命周期阶段上。如果插件没有默认生命周期阶段,那么插件目标将不会被执行。

    通过以上的配置,现在执行mvn verify将看到maven-source-plugin的jar-no-fork目标被执行。

    插件配置

    几乎每个插件都有可配置的参数,以满足不同的构建需求。

    命令行插件配置

    执行生命周期或插件目标时,如果某个插件目标被调用,那么就可以通过-D{parameter}的形式指定参数的配置。如:

    mvn myquery:query -Dquery.url=http://maven.apache.org
    1
    POM 文件全局配置

    在project > build > plugins > plugin > configuration中配置的参数,将在每一次执行该插件的时候起作用。

    <project>
    [...]
    <build>
    [...]
    <plugins>
    <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.5.1</version>
    <configuration>
    <source>1.7</source>
    <target>1.7</target>
    </configuration>
    </plugin>
    </plugins>
    [...]
    </build>
    [...]
    </project>

    以上配置了maven-compiler-plugin插件使用 java 1.7 编译源代码,那么无论在compile生命周期中被调用,还是手动调用该插件,都会使用 java 1.7。

    POM 文件插件任务配置

    在 project > build > plugins > plugin > executions > execution > configuration 中配置的参数,只在该任务被执行时有效。

    命令行执行插件

    执行mvn -h看到如下帮助信息:

    $ mvn -h

    usage: mvn [options] [<goal(s)>] [<phase(s)>]
    options:mvn 命令选项
    goal(s):插件目标
    phase(s):生命周期阶段
    根据以上知识,如果执行以下命令:

    mvn clean dependency:copy-dependencies package
    1
    那么,clean阶段会首先执行(包括在它以前的阶段),然后是dependency:copy-dependencies插件目标,最后package阶段被执行(包括它之前的阶段)。而生命周期阶段被执行也就是插件目标被执行,所以整个命令最终就是不同的插件目标执行,然后完成了想实现的目标。

    插件前缀解析

    Maven中标识插件也是使用groupId:artifactId:version,但是实例中命令行调用都只有一个前缀和目标,比如dependency:copy-dependencies。

    Maven允许使用插件前缀来映射groupId:artifactId,Maven有多种方式来指定这种映射方式。

    根据约定确定

    默认情况下,Maven通过去除artifactId上通过连字符连接的maven和plugin来确定插件前缀:

    maven-${prefix}-plugin:官方插件使用的artifactId
    ${prefix}-maven-plugin:其他来源的插件(如 tomcat 插件:tomcat7-maven-plugin)
    使用以上两种方式,Maven能够通过artifactId的形式,自动确定插件前缀。这样你就能够使用tomcat7作为前缀来调用 tomcat 插件的目标,如tomcat7:run。

    手动指定

    可以在声明插件时手动指定插件前缀:

    <project>
    ...
    <build>
    ...
    <plugins>
    ...
    <plugin>
    <artifactId>maven-plugin-plugin</artifactId>
    <version>2.3</version>
    <configuration>
    ...
    <goalPrefix>somePrefix</goalPrefix>
    </configuration>
    </plugin>
    </plugins>
    </build>
    </project>
    现在可以使用somePrefix前缀来使用插件了:

    mvn somePrefix:goal
    1
    配置Maven搜索插件前缀

    如果,每个人都自己指定插件前缀,那么每个人的配置都不一样,那么岂不麻烦。maven就是为了消除这些麻烦,所以使用约定优于配置的原则来构建。

    所以,很多插件都自己指定了插件前缀。那么,Maven是如何解析这些前缀的呢?

    这些映射关系都放在groupId/maven-metadata.xml中,所以,Maven使用如下的方式解析插件前缀:

    在${groupId}路径下,下载远程仓库的maven-metadata.xml到该路径,然后重命名为maven-metadata-${repoId}.xml。
    合并${groupId}路径下的maven-metadata-local.xml,然后加载合并后的文件。
    然后在合并后的元数据中查找插件前缀,如果没找到就在下一个插件组重复这一过程。
    如下是Maven官方插件(groupId为org.apache.maven.plugins)路径下的maven-metadata.xml文件的片段:

    <plugins>
    <plugin>
    <name>Apache Maven Clean Plugin</name>
    <prefix>clean</prefix>
    <artifactId>maven-clean-plugin</artifactId>
    </plugin>
    <plugin>
    <name>Apache Maven Compiler Plugin</name>
    <prefix>compiler</prefix>
    <artifactId>maven-compiler-plugin</artifactId>
    </plugin>
    <plugin>
    <name>Apache Maven Dependency Plugin</name>
    <prefix>dependency</prefix>
    <artifactId>maven-dependency-plugin</artifactId>
    </plugin>
    </plugins>

    可以看到,每个plugin元素指定了prefix和artifactId,所以这个插件前缀就唯一确定了groupId:artifactId,再结合声明插件时指定的version信息,Maven就完成了插件的解析。
    Maven默认会搜索如下两个groupId下的插件:

    org.apache.maven.plugins
    org.codehaus.mojo
    如果,需要Maven搜索更多groupId下的插件,那么需要在settings.xml中配置<pluginGroups>元素:

    <pluginGroups>
    <pluginGroup>org.codehaus.modello</pluginGroup>
    </pluginGroups>
    这样,Maven就会首先搜索org.codehaus.modello下的插件前缀,如果没有找到,再搜索org.apache.maven.plugins、org.codehaus.mojo。也就是<pluginGroup>中配置的groupId优先级高于Maven默认的。这样,可以使用这一机制来覆盖默认的插件前缀的解析。

    依赖:
    provided 不具有传递性
    optional 依赖可选的,不具有传递性


    访问属性:
    ${env.propertyName} 环境变量
    ${project.propertyName} 项目的
    ${settings.localRepository} maven配置文件中的
    ${java.home} java.lang.System.getProperties()
    ${hello.world} pow文件中的


    将source-plugin置于顶层或parent的pom中并不会发挥作用,必须置于具体项目的pom中。


    查看插件信息
    mvn help:describe -Dplugin=org.apache.maven.plugins:maven-assembly-plugin:3.0.0 -Ddetail
    mvn assembly:help

  • 相关阅读:
    Liskov替换原则
    OCP开放封闭原则
    SRC单一职责原则
    什么是敏捷设计
    [WCF编程]13.并发:服务并发模式
    [WCF编程]12.事务:服务事务编程(下)
    [WCF编程]12.事务:服务事务编程(上)
    [WCF编程]12.事务:Transaction类
    [WCF编程]12.事务:事务传播
    [WCF编程]12.事务:事务协议与管理器
  • 原文地址:https://www.cnblogs.com/cghhnty/p/7837612.html
Copyright © 2020-2023  润新知