转载

我在工作中是这样使用Maven

上次说到我在工作中是这样使用Git ，已经是1个月前的故事了，时间啊，就这样慢慢流逝了。

这次来说说 maven 这玩意，同样还是那句话，maven对我而言只是工具，一些常规操作已经足够了，有空有兴趣才会去深入研究它。接下来会记录下自己使用maven时需要 注意 和 理解 的地方，至于那些基本概念和环境配置的问题，相信大家都懂。

maven仓库可分为 本地仓库 和 远程仓库 。

如果公司自己有搭建maven私服，那么还可以细分为 本地仓库 、 私服仓库(内网) 、 中央仓库(外网) 。

私服是指公司内网搭建的maven仓库，可供公司内部人员使用。

pom.xml里依赖jar包的寻找流程：

本地仓库找 ，找到直接用，不需要联网。
本地找不到， 私服仓库找 ，找到就下载到本地，以供下次直接使用。
私服找不到，会直接去 中央仓库找 ，然后下载到私服、本地，以供下次直接使用。

没私服的话，本地仓库找不到就直接去中央仓库找。

构建过程

maven构建过程的各个环节，代表maven工作的某个阶段

清理：将以前编译得到的 旧的class字节码文件删除 ，为下一次编译做准备。
编译：将Java源程序 编译成class字节码 。
测试：自动测试， 自动调用junit程序 。
报告：测试程序执行的结果。
打包：动态Web工程 打war包 ，java工程 打jar包 。
安装：将打包得到的文件 复制到仓库中指定位置 。
发布： 拷贝最终的工程包到远程仓库 ，以供其他开发人员使用。

maven实际工作时，顺序不一定从上到下。几个阶段是重要阶段，并不是maven的全部阶段。具体执行什么阶段，执行顺序是啥，依赖于它的生命周期。

有些文章会说到最后一个构建阶段：部署->将动态Web工程生成的war包复制到Servlet容器的指定目录下，使其运行。这需要在tomcat这种servlet容器配置点什么，然后再执行maven相关命令，war包就会自动部署到容器下。不过我现在开发基本都是在SpringBoot环境下，war包部署就不存在了。有兴趣再去熟悉熟悉。

生命周期

三套 相互独立 的生命周期，互不影响，定义了 构建环节的执行顺序 。

clean生命周期：构建之前进行一些 清理工作 。
default生命周期： 常用且核心 ，包括编译、测试、打包、安装、发布等
site生命周期：生成项目报告、站点。发布站点。(我没怎么用过....)

依赖上述的构建过程和生命周期， maven执行任何一个阶段的时候，它前面的所有阶段都会执行 。

例如我们执行 mvn install 的时候，代码会被编译，测试，打包。但不会clean(清理)，因为install和clean是在不同的生命周期里，但我们可以结合使用，如：mvn clean install

idea内置maven界面也说明这一点，点击生命周期的某一个阶段，maven会把前面到此阶段都执行下，不信你可以试试。我在工作中是这样使用Maven

maven命令

除了通过idea的界面操作maven，我们也可以手打命令，不然在linux系统上你怎么搞？

清理 mvn clean
编译 mvn compile
测试 mvn test
打包 mvn package
安装 mvn install
发布 mvn deploy

执行maven构建命令，必须在pom.xml所在的目录我在工作中是这样使用Maven

根据maven生命周期，当你执行mvn install时， compile、test、package、intall会依次执行，mvn deploy同理。

实际开发中，我都是直接敲命令编译打包安装，用得最多的是

mvn clean install -Dmaven.test.skip=true -U

加上clean是先把文件清理干净，100%确保install后是最新修改的文件。

如果当前项目并不需要被任何其他项目依赖，就没必要install了，执行mvn clean package即可

mvn命令支持带参数

-U ：该参数能强制让Maven检查所有SNAPSHOT依赖更新，确保集成基于最新的状态。
-Dmaven.test.skip=true ：不执行测试用例，也不编译测试用例类。
-DskipTests ：不执行测试用例，但编译测试用例类生成相应的class文件至target/test-classes下。
-P ：多环境打包（后面会说）

maven仓库除了保存jar包，还有插件。核心程序仅定义了抽象的生命周期，具体工作还是得由特定的插件来完成。

一般我使用maven-compiler-plugin 插件来编译，定义的jdk版本一定要跟你开发使用的jdk版本一致，不然后续打包会出错等各种奇怪问题。

pom.xml的build节点里

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
                <encoding>UTF-8</encoding>
            </configuration>
        </plugin>
    </plugins>
</build>
复制代码

依赖范围

标识jar包能被管理的范围。

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>5.1.3</version>
    <scope>compile</scope>
</dependency>
复制代码

compile：依赖项目参与编译、测试、部署运行
test：仅参与测试，包括测试代码的编译、运行
provided：可以参与编译、测试，但打包不会引入

一张表格来总结

	compile	test	provided
主程序	✓	×	✓
测试程序	✓	✓	✓
参与部署	✓	×	×

上述3个比较常见，还有另外3个不常见的

runtime：无需参与编译、后期测试和运行周期需参与，一般用于数据库驱动jar包
system：jar包从本地次磁盘路径拿，不用在maven仓库，一般加个systemPath节点表示具体路径

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
    <version>5.1.3</version>
    <scope>system</scope>
    <systemPath>../xx/xx.jar</systemPath>
</dependency>
复制代码

import：导入另一jar包的东西，仅支持在<dependencyManagement>中定义（后续有例子）

注意：非compile的依赖不能传递！

打包方式

packaging节点里

<groupId>com.goku</groupId>
<artifactId>goku-manage</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
复制代码

pom：依赖文件打包，打出来可以作为其他项目的maven依赖，子工程继承父工程，子工程可直接使用父工程的配置，一般用在聚合工程来做jar包的版本控制。
jar：普通项目打包，开发时要引用通用类，打成jar包便于存放管理。SpringBoot内置tomcat，打成jar可直接运行。
war：web项目打包，打成war包部署到服务器。

聚合与继承

聚合工程里有多个pom.xml

父工程通过modules聚合子工程，该工程执行maven命令时，2个子工程也会执行

<modules>
    <module>goku-user</module>
    <module>goku-order</module>
</modules>
复制代码

子工程通过parent标签继承父工程，可直接引用父工程的配置项

<parent>
    <groupId>com.goku</groupId>
    <artifactId>goku-manage</artifactId>
    <version>1.0-SNAPSHOT</version>
</parent>
复制代码

至于聚合模块的好处有很多，真真切切让我感受到的有其二

依赖包划分合理，职责结构清晰，不存在一个庞大的pom.xml。
内部代码改动后只需要编译当前工程，耗时减少。特别适合分布式项目。

统一版本号

聚合工程里，版本号可以统一配置，统一管理。同个公司的不同项目，所有依赖包版本最好相同。

有些公司会单独建一个工程，只用来统一版本号，打包成pom形式，给公司内部各个项目继承。

顶层父工程的pom文件里的properties节点

<properties>
    <java.version>1.8</java.version>
    <plugin.jdk.version>1.8</plugin.jdk.version>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <spring-boot.version>2.1.3.RELEASE</spring-boot.version>
    <fasterjson.version>1.2.12</fasterjson.version>
</properties>
复制代码

dependency的vesion引用配置好的版本号

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <version>${spring-boot.version}</version>
</dependency>
复制代码

dependencyManagement统一管理版本

请注意<scope>import</scope>

<dependencyManagement>
    <dependencies>
        <dependency>
            <!-- Import dependency management from Spring Boot -->
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>2.0.0.RELEASE</version>
            <type>pom</type>
            <!--导入spring-boot-dependencies里的配置，一定程度上解决了单继承问题。-->
            <scope>import</scope>
         </dependency>
         <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-api</artifactId>
            <version>${slf4j.version}</version>
        </dependency>
        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>fastjson</artifactId>
            <version>${fasterjson.version}</version>
        </dependency>
     </dependencies>
 </dependencyManagement>
复制代码

说明：

dependencyManagement只是声明依赖，不会引入依赖。
子模块不会继承父模块中dependencyManagement所有预定义的depandency，若想使用还需引入需要的依赖，只不过不需要加version节点了。
据说在父模块中严禁直接使用depandencys预定义依赖，应该做到按需引入。

多环境打包

项目打包时区分环境，实际上是根据不同环境生成不同的配置文件。

一般区分本地、开发/测试、线上。

pom.xml里的build和profiles（以下配置仅针对SpringBoot的yml文件）

<build>
    <!-- 打包后文件名称：项目名-环境-版本 -->
    <finalName>${project.artifactId}</finalName>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <!-- 开启过滤替换功能-->
            <filtering>true</filtering>
            <includes>
                <!-- 项目打包完成的包中只包含当前环境文件 -->
                <include>application.yml</include>
                <include>application-${profileActive}.yml</include>
                <include>**/*.xml</include>
                <include>**/*.properties</include>
            </includes>
        </resource>
    </resources>
</build>


<!-- 多环境配置方案 -->
<profiles>
    <profile>
        <id>local</id>
        <properties>
            <profileActive>local</profileActive>
        </properties>
        <activation>
            <!-- 默认情况下使用本地开发配置 如 打包时不包含 -p 参数-->
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <!-- 打包命令package -P test -->
    <profile>
        <id>test</id>
        <properties>
            <profileActive>test</profileActive>
        </properties>
    </profile>
    <!-- 打包命令package -P prod -->
    <profile>
        <id>prod</id>
        <properties>
            <profileActive>prod</profileActive>
        </properties>
    </profile>
</profiles>
复制代码

maven命令带参数-P，如：mvn clean install -P test

项目打包后只保留application.yml、ymlapplication-test.yml

application.yml里的@profileActive@也会被替换成test 我在工作中是这样使用Maven

最终打包生成的文件我在工作中是这样使用Maven

setting.xml

localRepository

指定本地仓库地址，不配置就放在默认路径${user.home}/.m2/repository

<localRepository>D:/develop/maven/Repmaven</localRepository>
复制代码

server

公司搭建了maven私服，上传下载需要认证，就需要配置。

NOTE: You should either specify username/password OR privateKey/passphrase, since these pairings are used together.

可配置账号密码或私钥形式，支持多个server

<servers>
    <server>
        <!--id需要与repository或mirror中的id相对应-->
        <id>server01</id>
        <username>admin</username>
        <password>SwaDmin159</password>
    </server>
    <server>
        <id>server02</id>
        <privateKey>/xxx/.ssh/id_dsa</privateKey>
        <passphrase>some_passphrase</passphrase>
        <filePermissions>664</filePermissions>
        <directoryPermissions>775</directoryPermissions>
        <configuration></configuration>
    </server>
</servers>
复制代码

mirror

仓库镜像，中央仓库的代理，如果配置了镜像，就直接去镜像中下载依赖。它相当于一个拦截器，拦截maven对默认中央仓库的请求，把请求里的远程仓库地址，重定向到mirror里配置的地址。

  <mirrors>
     <mirror>
         <id>nexus-aliyun</id>
         <mirrorOf>central</mirrorOf>
         <name>Nexus aliyun</name>
         <url>http://maven.aliyun.com/nexus/content/groups/public</url>
    </mirror>
  </mirrors>
复制代码

profile and activeProfiles

所有项目使用私服仓库，可在setting.xml配置，profile节点配置repositories，最后再激活profile。

当然，私服里不只一个仓库，可配置多个repository。

 <profile>
     <repositories>  
        <repository>  
            <!-- id需要与私服里仓库的id对应 -->
            <id>public</id>  
            <name>public</name>  
            <url>http://xxx.com/nexus/content/groups/public/</url>             
            <layout>default</layout>              
        </repository> 
    </repositories>  
</profile>

<activeProfiles>
    <activeProfile>public</activeProfile>
</activeProfiles>
复制代码

若只想针对某个项目，则在当前项目的pom.xml配置私服，repositories节点下配置即可

<repositories>
    <repository>
        <!-- id需要与私服里仓库的id对应 -->
        <id>public</id>
        <name>public</name>
        <url>http://xxx.com/nexus/content/groups/public/</url>             
        <releases>
            <enabled>true</enabled>
        </releases>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
    </repository>
</repositories>
复制代码

distributionManagement

有时我们自己开发的模块需要被其他部门的开发人员使用，就需要发布到私服。

执行mvn deploy前，需配置distributionManagement。

快照版本跟发布版本分别存储到不同仓库地址。

<distributionManagement>
    <repository>
        <id>release</id>
        <name>Project Release</name>
       <url>http://xxx.com/nexus/content/groups/release/</url>             
    </repository>
    <snapshotRepository>
        <id>snapshots</id>
        <name>Project SNAPSHOTS</name>
           <url>http://xxx.com/nexus/content/groups/snapshot/</url>      
    </snapshotRepository>
</distributionManagement>
复制代码