标签：enabled   cts   ict   lin   阶段   apach   proc   lse   编译   

Maven实战1

一、maven的安装和配置

1. Windows

官网下载-->配置环境变量-->mvn --version测试可用

2. Linux

自行apt安装...

3. 一条有用的maven命令

# Displays a list of the platform details like system properties and environment variables.
# Maven会自动下载maven-help-plugin，包括pom和jar等依赖
mvn help:system

4. 设置HTTP代理

如果公司禁止访问外网，这也就限制了Maven中央仓库的访问。设置代理，通过代理访问

setting.xml（apache-maven-3.6.1\conf\下）新增结点

<proxies>
    <!-- proxy
     | Specification for one proxy, to be used in connecting to the network.
     |
    <proxy>
      <id>optional</id>
      <active>true</active>
      <protocol>http</protocol>
      <username>proxyuser</username>
      <password>proxypass</password>
      <host>proxy.host.net</host>
      <port>80</port>
      <nonProxyHosts>local.net|some.host.com</nonProxyHosts>
    </proxy>
    -->
  </proxies>

二、maven的使用入门

1. pom文件的编写

pom文件类似于Makefile或build.gradle等配置文件，即使没有代码，空的文件夹也是可以进行maven管理。一个最简单的pom.xml：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <!-- 指定pom模型的版本，对于maven2及3只能是4.0.0 -->
    <modelVersion>4.0.0</modelVersion>

    <!-- 公司名+项目名 -->
    <groupId>com.hito.maven</groupId>
    <!-- 项目名子模块 -->
    <artifactId>hello-maven</artifactId>
    <!-- 模块版本号 snapshot为快照，既不稳定版本 -->
    <version>1.0-SNAPSHOT</version>
    <!--classfiier标签很少使用，用来帮助定义构建输出的一些附属构件。如一些jar，包含java文档和源代码-->
</project>

2. 编写主代码

直接通过idea新建一个空的Java Maven项目，注意下面main与test文件夹，默认规定测试代码位置

│  pom.xml     
└─src
    ├─main
    │  ├─java
    │  │  └─com
    │  │      └─hito
    │  │          └─maven
    │  │                  HelloMaven.java
    │  │                  
    │  └─resources
    └─test
        └─java

• mvn clean compile 可以发现生成了target目录

2.1 测试代码

1. 引入依赖坐标

   <dependency>
           <groupId>junit</groupId>
           <artifactId>junit</artifactId>
           <version>4.12</version>
           <scope>test</scope>
    </dependency>

2. 测试代码编写

   package com.hito.maven;
   
   import org.junit.Test;
   import static org.junit.Assert.*;
   /**
    *
    * @author HitoM
    * @date 2019/8/20 23:25
    **/
   public class HelloTest {
   
       @Test
       public void testHello(){
           HelloMaven helloMaven = new HelloMaven();
           assertEquals(helloMaven.sayHello(), "HelloMaven");
       }
   }

3. mvn clean test进行测试

3. 依赖范围

在上面的依赖坐标中你应该注意到：scope标签，它表示依赖范围，它有五个值

• test：依赖只对test中的代码有效。在main中你会发现无法导入junit包，如果改为compile则可以。

• compile：缺省值，表示在运行，打包，测试几个声明周期中，对应的jar包都是存在可用的。classpath 中可用，同时它们也会被打包

• runtime：运行时范围。编写代码时，不会参加编译，仅运行时有效。即对于测试和运行class-path有效，编译无效。

  比如JDBC驱动，我们在配置文件中只会配置JDBC的驱动类的完整路径，运行时才会使用反射获取真正的实例.

  再比如log4j，log4j其实是一套日志框架和规范。apache有api接口定义和core实现，我们可以使用apache的core实现也可以使用其他的实现，如jdk中的Logging。那么我就可以这么去实现pom，正常编码时使用接口，程序真正运行是core

  <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-api</artifactId>
      <version>2.11.1</version>
      <scope>compile</scope>
  </dependency>
  
  <dependency>
      <groupId>org.apache.logging.log4j</groupId>
      <artifactId>log4j-core</artifactId>
      <version>2.11.1</version>
      <scope>runtime</scope>
  </dependency>

  在这其中发现：log4j-core中其实是有log4j-api依赖的，为什么没有发生冲突呢？因为两者版本一致。那如果版本不一致log4j-api 2.11.1 log4j-core2.12.1，我们应该怎么处理冲突呢？

  

  版本不一致是要注意，一般高版本是兼容低版本的，所以在使用exclusions时保留的应该是高版本。在这里如果排除log4j-core2.12.1中的log4j-api，在pom dependencies目录中的log4j-api2.11.1是无法满足core要求的。解决办法：升高log4j-core版本号，然后exclusion。

• provided：类似compile，对于编译和测试class-path有效，运行时无效。期望JDK、容器或使用者会提供这个依赖,正式包中不会有依赖。eg：servlet-api

• system：与provided的依赖范围完全一致，但是必须使用systemPath显示指定依赖文件的路径，容易造成不可移植性，慎用！

  <dependency>
      <groupId>com.google.code</groupId>
      <artifactId>kaptcha</artifactId>
      <version>2.3.2</version>
      <scope>system</scope>
    <systemPath>${project.basedir}/libs/kaptcha-2.3.2.jar</systemPath>
  </dependency>

  依赖范围（Scope）	对于编译class-path有效	对于测试class-path有效	对于运行时class-path有效	例子
  compile	Y	Y	Y	spring-core
  test	N	Y	N	JUnit
  provided	Y	Y	N	servlet-api
  runtime	N	Y	Y	JDBC驱动
  system	Y	Y	N	本地的，Maven仓库之外的类库文件

4. 打包和运行

4.1 打包

? 通过maven-compiler-plugin的package命令mvn clean package即可打包。mvn install可以将生成的包安装在本地，这样其他依赖可以直接使用。

4.2 打可运行包

上面的方式生成的是依赖jar包，如果想要生成带有Main函数的可执行jar包需要怎么办呢？有三种常见的Maven打包插件，maven-jar-plugin、maven-shade-plugin和maven-assembly-plugin，这里通过maven-shade-plugin来实现打可执行包操作

<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.2.1</version>
        <configuration>
            <transformers>
                <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                    <mainClass>com.hito.maven.Main</mainClass>
                </transformer>
            </transformers>
        </configuration>
        <executions>
            <execution>
                <phase>package</phase>
                <goals>
                    <goal>shade</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
</plugins>

mvn package即可在target下发现打包成功，通过java -jar xxx.shade.jar即可执行。

三、依赖

1. 依赖传递

A依赖于B，B依赖于C，那么A对于B是第一直接依赖，B对于C是第二直接依赖，A对于C是传递性依赖。

依赖范围影响传递性依赖如下表，其中第一列表示第一直接依赖范围，第一行表示第二直接依赖范围。

2. 依赖调解

Maven是如何处理依赖冲突的呢？如何调解？

• 第一原则，路径最短优先。A->B->Y(1.0),A->Y(2.0),那么A是依赖于Y(2.0)的
• 第二原则：第一声明优先。如果两者路径相同，谁在pom中先声明，就依赖谁。

3. 可选依赖

B是一个持久层隔离工具包，它支持多种数据库，Mysql、PostgreSQL，构建时需要两种jar，但是B作为依赖被使用时只会依赖一种数据库。这样的话，B中需要声明两种可选依赖，而且是只对B可见可用。A如果想要依赖B，还需显示声明MySQL依赖或PostgreSQL中一种。

<!--B-->
<dependencies>
    <dependency>
        <groupId>xxx</groupId>
        <artifactId>xxx</artifactId>
        <optional>true</optional>
    </dependency>
    <dependency>
        <groupId>yyy</groupId>
        <artifactId>yyy</artifactId>
        <optional>true</optional>
    </dependency>
</dependencies>

<!--A-->
<dependencies>
    <dependency>
        <groupId>B</groupId>
        <artifactId>B</artifactId>
    </dependency>
    <!--\声明B中所用具体实现-->
    <dependency>
        <groupId>yyy</groupId>
        <artifactId>yyy</artifactId>
    </dependency>
</dependencies>

4. 最佳实践

对于Maven的总结，就是最佳实践辣

4.1 排除依赖

传递依赖会给项目带来很多隐式依赖，这就导致会跟项目本身显示添加的依赖产生冲突，可以通过排除依赖的方式使项目使用显示的依赖而不是隐式依赖。

<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.11.1</version>
    <scope>runtime</scope>
    <exclusions>
        <exclusion>
            <!--这里并不需要指定版本号-->
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
        </exclusion>
    </exclusions>
</dependency>

4.2 归类依赖

依赖与依赖之间是有关联的，比如Spring全家桶。这样我们就可以在Pom文件的properties标签下声明统一的版本号，然后通过${}引用，可以做到依赖版本的统一管理。

4.3 优化依赖

可以运用如下的命令查看解析当前项目的依赖：

1. 依赖列表 mvn dependency:list

2. 查看依赖树 mvn dependency:tree

3. 依赖分析 mvn dependency:analyze

   这个结果中有两个重要的部分：

   • Used undeclared dependencies：项目中使用了未显示声明的依赖，即在代码中使用了由直接依赖传递的依赖，这样在升级直接依赖的时候不易发现版本变化，这是一种隐藏的威胁。
   • Unused declared dependencies：明明未使用，但是显示声明了的依赖。注意，不应该将此类依赖简单删除，因为analyze只会分析编译代码和测试代码，运行时需要的依赖它是无法发现的。所以我们应该仔细分析后再处理。

四、生命周期和插件

1. clean build compile install 是什么？怎么来的？
2. maven为什么能够做到这些？

1. 何为生命周期

在Maven出现之前，项目的生命周期就已经存在了，Developer对项目进行清理、编译、测试和部署，Maven对所有的构建过程进行了抽象和统一。 Maven的生命周期是抽象的，这就意味着生命周期本身不做任何实际的工作，而是由插件来完成。如同Maven声明抽象方法，而具体实现由插件完成。

2. 生命周期详情

2.1 三套生命周期

一开始以为Maven的生命周期为一个整体，其实不然，Maven拥有三套相互独立的生命周期：

1. clean：清理项目，包含三个阶段
   • pre-clean
   • clean
   • post-clean
2. default：构建项目
   • validate： validate the project is correct and all necessary information is available
   • initialize
   • generate-sources
   • process-sources
   • generate-resources
   • process-resources
   • compile：编译项目的主源码
   • process-classes
   • generate-test-sources
   • process-test-sources
   • .....
   • test：使用单元测试框架运行测试，测试代码不会被打包或部署
   • package：接受编译好的代码，打包成可发布的格式，如jar、war等
   • verify： run any checks on results of integration tests to ensure quality criteria are met.
   • install：将包安装到本地仓库，供本地其他的Maven项目使用
   • depoy：将包复制到远程仓库，供其他开发人员和Maven项目使用
3. site：建立项目站点（一个用来浏览项目信息的本地小网站一样）
   • pre-site
   • site
   • post-site
   • site-deploy

2.2 命令行和生命周期

从命令行执行Maven任务的最主要方式就是调用Maven的生命周期阶段。各个生命周期是相互独立的，而一个生命周期阶段是有前后依赖关系的

• mvn clean：实际执行 pre-clean和clean
• mvn test：调用default的test阶段，实际执行的生命周期为validate、initialize直到test的所有阶段
• mvn install：调用clean和install阶段，实际执行的阶段为pre-clean、clean阶段以及default生命周期的从validate到install的所有阶段，该命令结合了两个生命周期阶段，在执行真正的项目构建之前清理项目是一个很好的实践
• mvn clean deploy site-deploy：该命令调用clean生命周期的clean阶段、default生命周期的deploy阶段以及site生命周期的site-deploy阶段。实际执行为pre-clean、clean阶段，default的所有生命周期阶段以及site的所有生命周期阶段。

3. 插件

我们知道Maven的核心仅仅定义了抽象的生命周期，具体的任务交与插件完成，插件以独立的构件形式存在。Maven的核心分发包3MB左右，Maven会在需要的时候下载并使用插件。插件是如何和生命周期绑定关系的呢？在这之前我们必须了解插件目标

3.1 插件目的

对于插件本身，为了能够复用代码，它往往能够完成多个任务。例如maven-dependency-plugin，它能够分析项目依赖（mvn dependency:analyze），列出项目依赖树等。为每个这样的功能编写独立的插件显然是不可取的，因为这些任务背后有可以复用的代码，因此将这些功能聚集在一个插件里，每个功能就是一个插件的目标。你可以在Mavne官网插件列表中查看 各个plugin的goals。

3.2 插件绑定

Maven的生命周期与插件相互绑定，用以完成实际的构建任务。具体而言，生命周期的阶段与 插件的目的相互绑定，已完成某个具体的构建任务。例如项目编译这一任务，它对应了default生命周期的compil这一阶段，而maven-compiler-plugin这一插件的compile目标能够完成该任务。因此将它们绑定，就能实现编译的目的。可是我们在pom中并没有配置绑定关系，它们是如何标定的呢？

3.3 内置绑定

为了让用户几乎不用任何配置就能构建Maven项目，Maven在核心为一些主要的生命周期阶段绑定了很多插件的目标，当用户通过命令行调用生命周期阶段的时候，对应的插件目标就会执行相应的任务。

• clean生命周期与插件目标待定绑定关系

  生命周期阶段	插件目标
  pre-clean clean post-clean	maven-clean-plugin：clean

• default生命周期的内置插件绑定关系和具体任务

  生命周期阶段	插件目标	执行任务
  process-resources	maven-resources-plugin:resources	复制主资源文件到主输出目录
  compile	maven-compiler-plugin：compile	编译主代码值主输出目录
  test	maven-surefire-plugin：test	执行测试用例
  package	maven-jar-plugin：jar	创建项目jar包
  install	maven-install-plugin：install	将项目输出构建安装到本地仓库
  ...	...	...

  这些都可以在Idea中的maven插件中找到。

3.4 自定义绑定

除了内置绑定，当然还可以自己选择将某个插件目标绑定到生命周期的某个阶段。

一个常见的例子就是创建项目的源码jar包，内置的插件并没有涉及到这一任务。maven-source-plugin可以帮助我们完成任务，他的jar-no-fork目标能够将项目的主代码打成jar文件，可以将其绑定到default生命周期的verify阶段上，在执行完集成测试和安装构件之前创建源码jar包。

<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>

执行mvn verify就会发现target文件下打包成功。

[INFO] --- maven-source-plugin:2.1.1:jar-no-fork (attach-sources) @ hello-maven ---
[INFO] Building jar: E:\IdeaProjects\hellomaven\target\hello-maven-1.0-sources.jar

有时候，即使不用过phase配置生命周期阶段，插件目标仍能绑定到生命周期中去，这是因为很多插件的目标在编写时已经定义了默认的绑定阶段。可以在 maven官网中查看。

3.5 插件配置

用户可以在Maven命令中使用-D参数，并伴随一个参数键=参数值的裤衩，来配置插件目标的参数。下面的例子就会跳过执行测试，

mvn install -Dmaven.test.skip = true

很多时候，有些参数很少变动，我们可以把它配置在pom文件中

 <plugin>
     <groupId>org.apache.maven.plugins</groupId>
     <artifactId>maven-compiler-plugin</artifactId>
     <version>3.8.1</version>
     <configuration>
         <source>1.8</source>
         <target>1.8</target>
     </configuration>
</plugin>

五、聚合与继承

1. 为什么SpringBoot项目中的pom.xml文件中很少的依赖信息，却发现其实依赖了一些未声明的信息？
2. 那么多依赖冲突就没有什么管理办法吗？

1. 聚合

一个 项目往往不是单一的模块，比如一个Web项目可能分为Service、Bean和Repositroy等，我们可以方便的使用Maven来管理模块之间的依赖和聚合关系。

<modules>
    <module>bean</module>
</modules>

在bean中

<parent>
    <artifactId>maven-integration</artifactId>
    <groupId>com.hito</groupId>
    <version>0.0.1-SNAPSHOT</version>
    <!--如果父模块不在上一层目录，可以通过此配置设置-->
    <relativePath>xxx</relativePath>
</parent>

2. 继承

2.1 哪些属性是可以被继承的呢

• groupId
• version
• description
• distributionManagement：项目的部署管理
• properties：自定义的Maven属性
• dependencies：依赖配置
• dependencyManagement：依赖管理
• build

2.2 依赖管理

通过声明parent，子模块即可使用父模块中的依赖，可是子模块并不需要父模块中的所有依赖，那就需要依赖管理了。

Maven提供的dependencyManagement元素既能让子模块继承到父模块的依赖配置，又能保证子模块依赖的灵活性。在dependencyManagement中声明的依赖不会引入实际的依赖，不过能够约束dependencies下的依赖使用。

<dependencyManagement>
    <!--在这里声明的依赖不会被引入-->
    <dependencies>
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-mongodb</artifactId>
            <version>2.2.0.RC2</version>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <!--真正引入，子模块也可以用这种方式引入，统一控制版本信息-->
    <dependency>
        <groupId>org.springframework.data</groupId>
        <artifactId>spring-data-mongodb</artifactId>
    </dependency>
</dependencies>

build元素下的pluginManagement有同样的功能，子模块可灵活继承父模块中声明的插件。

2.3 super pom

任何一个项目都隐式的继承一个超级pom文件，该文件在MAVEN_HOME/lib/maven-model-builder-x.x.x.jar中，这就是为什么一个只声明proupID和artifactId的maven工程能够运行的原因。

<project>
    <repositories>
    <repository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
    </repository>
  </repositories>

  <pluginRepositories>
    <pluginRepository>
      <id>central</id>
      <name>Central Repository</name>
      <url>https://repo.maven.apache.org/maven2</url>
      <layout>default</layout>
      <snapshots>
        <enabled>false</enabled>
      </snapshots>
      <releases>
        <updatePolicy>never</updatePolicy>
      </releases>
    </pluginRepository>
  </pluginRepositories>
    <build>
    <directory>${project.basedir}/target</directory>
    <outputDirectory>${project.build.directory}/classes</outputDirectory>
    <finalName>${project.artifactId}-${project.version}</finalName>
    <testOutputDirectory>${project.build.directory}/test-classes</testOutputDirectory>
    <sourceDirectory>${project.basedir}/src/main/java</sourceDirectory>
    <scriptSourceDirectory>${project.basedir}/src/main/scripts</scriptSourceDirectory>
    <testSourceDirectory>${project.basedir}/src/test/java</testSourceDirectory>
    <resources>
      <resource>
        <directory>${project.basedir}/src/main/resources</directory>
      </resource>
    </resources>
    <testResources>
      <testResource>
        <directory>${project.basedir}/src/test/resources</directory>
      </testResource>
    </testResources>
    <pluginManagement>
      <!-- NOTE: These plugins will be removed from future versions of the super POM -->
      <!-- They are kept for the moment as they are very unlikely to conflict with lifecycle mappings (MNG-4453) -->
      <plugins>
        <plugin>
          <artifactId>maven-antrun-plugin</artifactId>
          <version>1.3</version>
        </plugin>
        <plugin>
          <artifactId>maven-assembly-plugin</artifactId>
          <version>2.2-beta-5</version>
        </plugin>
        <plugin>
          <artifactId>maven-dependency-plugin</artifactId>
          <version>2.8</version>
        </plugin>
        <plugin>
          <artifactId>maven-release-plugin</artifactId>
          <version>2.5.3</version>
        </plugin>
      </plugins>
    </pluginManagement>
  </build>
    ....
</project>

3. 反应堆

一个多模块的项目中，反应堆指所有模块的一个构建结构。

3.1 构建顺序

一般来说，构建顺序是按照pom中声明的顺序自上而下的，但是如果子模块中间存在依赖关系的话，会优先构建依赖的模块。所以mavne的依赖结构是一个有向的非循环图（DAG）

3.2 剪裁反应堆

有时候，我只关心某一个或某些模块的构建，这时候就需要对反应堆进行剪裁。mvn命令后追加参数即可完成

• -am , --also-make构建所列模块的依赖
• -amd，同时构建依赖于所列模块的模块
• -pl, --projects 构建指定的模块
• -rf, -resume-from 从指定的模块恢复反应堆

例子

1. mvn clean install -pl account-email,account-persist，只构建声明的模块
2. mvn clean install -pl account-email,account-persist -am构建声明的模块及其依赖
3. mvn clean install -rf account-email，从account-email开始构建

Maven实战 1

标签：enabled   cts   ict   lin   阶段   apach   proc   lse   编译   

原文地址：https://www.cnblogs.com/hitomeng/p/11449511.html