乐趣区

关于maven:Maven

jiezi

Maven

次要内容

Maven 的简介

简介

​ Maven【[ˈmevən]】这个词能够翻译为 ” 专家 ”,“外行”。作为 Apache 组织中的一个颇为胜利的开源我的项目，Maven 次要服务于基于 java 平台的我的项目构建，依赖治理和我的项目信息管理。

​ 无论是小型的开源类库我的项目，还是大型的企业级利用；无论是传统的瀑布式开发，还是风行的麻利开发，Maven 都能大显神通。

我的项目构建

​ 不论你是否意识到，构建（build）是每一位程序员每天都在做的工作。早上来到公司，咱们做的第一件事就是从源码库签出最新的代码，而后进行单元测试，如果测试失败，会找相干的共事一起调试，修复错误代码。接着回到本人的工作上来，编写本人的单元测试及产品代码。

​ 认真总结一下，咱们会发现，除了编写源代码，咱们每天有相当一部分工夫花在了编译，运行单元测试，生成文档，打包和部署等繁琐且不起眼的工作上，这就是构建。如果咱们当初还手工这样做，那老本也太高了，于是有人用软件的办法让这一系列工作齐全自动化，使得软件的构建能够像全自动流水线一样，只须要一条简略的命令，所有繁琐的步骤都可能主动实现，很快就能失去最终后果。

我的项目构建工具

​ Ant 构建

​ 最早的构建工具，基于 IDE, 大略是 2000 年有的，过后是最风行 java 构建工具，不过它的 XML 脚本编写格局让 XML 文件特地大。对工程构建过程中的过程管制特地好

​ Maven【JAVA】

​ 我的项目对象模型，通过其形容信息来治理我的项目的构建，报告和文档的软件项目管理工具。它填补了 Ant 毛病，Maven 第一次反对了从网络上下载的性能，依然采纳 xml 作为配置文件格式。Maven 专一的是依赖治理，应用 Java 编写。

**Gradle**

​ 属于联合以上两个的长处，它继承了 Ant 的灵便和 Maven 的生命周期治理，它最初被 google 作为了 Android 御用管理工具。它最大的区别是不必 XML 作为配置文件格式，采纳了 DSL 格局，使得脚本更加简洁。

​ 目前市面上 Ant 比拟老，所以个别是一些比拟传统的软件企业公司应用，Maven 应用 Java 编写，是当下大多数互联网公司会应用的一个构建工具，中文文档也比拟齐全, gradle 是用 groovy 编写，目前比拟新型的构建工具一些初创互联网公司会应用，当前会有很大的应用空间。

Maven 的四大个性

依赖管理系统

​ Maven 为 Java 世界引入了一个新的依赖管理系统 jar 包治理 jar 降级时批改配置文件即可。在 Java 世界中，能够用 groupId、artifactId、version 组成的 Coordination（坐标）惟一标识一个依赖。

​ 任何基于 Maven 构建的我的项目本身也必须定义这三项属性，生成的包能够是 Jar 包，也能够是 war 包或者 jar 包。一个典型的依赖援用如下所示：

<dependency>
    <groupId>javax.servlet</groupId>   com.baidu
    <artifactId>javax.servlet-api</artifactId>  ueditor echarts
    <version>3.1.0</version>
</dependency>

坐标属性的了解

​ Maven 坐标为各种组件引入了秩序，任何一个组件都必须明确定义本人的坐标。

groupId

​ 定义以后 Maven 我的项目附属的理论我的项目 - 公司名称。（jar 包所在仓库门路）因为 Maven 中模块的概念，因而一个理论我的项目往往会被划分为很多模块。比方 spring 是一个理论我的项目，其对应的 Maven 模块会有很多，如 spring-core,spring-webmvc 等。

artifactId

​ 该元素定义理论我的项目中的一个 Maven 模块 - 我的项目名，举荐的做法是应用理论项目名称作为 artifactId 的前缀。比方：spring-bean、spring-webmvc 等。

version

​ 该元素定义 Maven 我的项目以后所处的版本。

多模块构建

​ 我的项目复查时 dao service controller 层拆散将一个我的项目合成为多个模块曾经是很通用的一种形式。

​ 在 Maven 中须要定义一个 parent POM 作为一组 module 的聚合 POM。在该 POM 中能够应用 标签来定义一组子模块。parent POM 不会有什么理论构建产出。而 parent POM 中的 build 配置以及依赖配置都会主动继承给子 module。

统一的我的项目构造

​ Ant 时代大家创立 Java 我的项目目录时比拟随便，而后通过 Ant 配置指定哪些属于 source，那些属于 testSource 等。而 Maven 在设计之初的理念就是 Conversion over configuration（约定大于配置）。其制订了一套我的项目目录构造作为规范的 Java 我的项目构造, 解决不同 ide 带来的文件目录不统一问题。

统一的构建模型和插件机制
<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <version>6.1.25</version>
    <configuration>
         <scanIntervalSeconds>10</scanIntervalSeconds>
         <contextPath>/test</contextPath>
    </configuration>
</plugin>

Maven 的装置配置和目录构造

Maven 的装置配置

查看 JDK 的版本

​ JDK 版本 1.7 及以上版本

下载 Maven

​ 下载地址：http://maven.apache.org/downl…

配置 Maven 环境变量

​ 解压后把 Maven 的根目录配置到零碎环境变量中 MAVEN_HOME，将 bin 目录配置到 path 变量中。

​ 注：maven 解压后寄存的目录不要蕴含中文和空格

查看 Maven 是否装置胜利

​ 关上 dos 窗口，执行 mvn -v

意识 Maven 目录构造

​ Maven 我的项目目录构造

工作: 手动创立一个 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">
                 
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.xxxx</groupId>
  <artifactId>maven01</artifactId>
  <version>0.0.1-SNAPSHOT</version>
  <packaging>jar</packaging>

  <name>maven01</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>    
  </dependencies>
  
</project>

Ps：标签定义解释

根目录下的第一个子元素 ModelVersion 指定以后 Pom 模型的版本，对于 Maven3 来说，它只能是 4.0.0。指定了以后 Maven 模型的版本号，对于 Maven2 和 Maven3 来说，它只能是 4.0.0

groupId 定义了我的项目属于哪个组，这个组往往和我的项目所在的组织和公司存在关联。比方：com.xxxx

artifactId 定义了以后 Maven 我的项目在组中惟一的 ID。Version  X.X.X- 里程碑
比方：1.0.0-SNAPSHOT     
第一个 X 大版本 有重大改革
第二个 X 小版本  修复 bug，减少性能
第三个 X 更新

里程碑版本：SNAPSHOT（快照，开发版）alpha（内部测试）beta（公开测试）Release | RC（公布版）GA（失常版本）应用 name 标签申明一个对于用户更为敌对的项目名称，尽管不是必须的，但还是举荐为每个 Pom 申明 name，以不便信息交换。
编写主函数
package com.xxxx.demo;
public class Hello{public static void main(String[] args) {System.out.println("hello maven");
    }
}
cmd 下编译并运行

​ cmd 上面，进入我的项目的根目录

​ 1. 编译 java 文件

​ mvn compile

​ 2. 执行 main 办法

​ mvn exec:java -Dexec.mainClass=“com.xxxx.demo.Hello”

​ 注：第一次下载会比较慢，要批改 maven 解压之后的 conf 目录下的 settings.xml。

1.1. 批改默认仓库地位
关上 maven 目录 -> conf -> settings.xml
增加仓库地位配置
<localRepository>F:/m2/repository</localRepository>
注：仓库地位改为本人本机的指定目录，"/" 不要写反

1.2. 更换阿里镜像, 放慢依赖下载
<mirror>  
      <id>nexus-aliyun</id>  
      <mirrorOf>central</mirrorOf>    
      <name>Nexus aliyun</name>  
      <url>http://maven.aliyun.com/nexus/content/groups/public</url>
</mirror>

如果编译不胜利，可能呈现的问题

1. 不是应用管理员权限执行 dos 命令
2. JDK 环境配置有问题，重装 JDK
3. 代码编写时，类外面没设置包名（如果编译时类没加包名，执行时也不须要加包名）

Maven 命令

​ 作为开发利器的 maven，为咱们提供了非常丰盛的命令，理解 maven 的命令行操作并纯熟使用常见的 maven 命令还是十分必要的，即便譬如 IDEA 等工具给我提供了图形界面化工具，但其底层还是依附 maven 命令来驱动的。

Maven 的命令格局如下：

mvn [plugin-name]:[goal-name]

命令代表的含意：执行 plugin-name 插件的 goal-name 指标

常用命令

命令

形容

mvn –version

显示版本信息

mvn clean

清理我的项目生产的临时文件, 个别是模块下的 target 目录

mvn compile

编译源代码，个别编译模块下的 src/main/java 目录

mvn package

我的项目打包工具, 会在模块下的 target 目录生成 jar 或 war 等文件

mvn test

测试命令, 或执行 src/test/java/ 下 junit 的测试用例.

mvn install

将打包的 jar/war 文件复制到你的本地仓库中, 供其余模块应用

mvn deploy

将打包的文件公布到近程参考, 提供其余人员进行下载依赖

mvn site

生成我的项目相干信息的网站

mvn eclipse:eclipse

将我的项目转化为 Eclipse 我的项目

mvn dependency:tree

打印出我的项目的整个依赖树

mvn archetype:generate

创立 Maven 的一般 java 我的项目

mvn tomcat7:run

在 tomcat 容器中运行 web 利用

mvn jetty:run

调用 Jetty 插件的 Run 指标在 Jetty Servlet 容器中启动 web 利用

留神：运行 maven 命令的时候，首先须要定位到 maven 我的项目的目录，也就是我的项目的 pom.xml 文件所在的目录。否则，必以通过参数来指定我的项目的目录。

命令参数

​ 下面列举的只是比拟通用的命令，其实很多命令都能够携带参数以执行更精准的工作。

-D 传入属性参数

例如：
mvn package -Dmaven.test.skip=true

​ 以 -D 结尾，将 maven.test.skip 的值设为 true, 就是通知 maven 打包的时候跳过单元测试。同理，mvn deploy-Dmaven.test.skip=true 代表部署我的项目并跳过单元测试。

-P 应用指定的 Profile 配置

​ 比方我的项目开发须要有多个环境，个别为开发，测试，预发，正式 4 个环境，在 pom.xml 中的配置如下：

<profiles>
      <profile>
             <id>dev</id>
             <properties>
                    <env>dev</env>
             </properties>
             <activation>
                    <activeByDefault>true</activeByDefault>
             </activation>
      </profile>
      <profile>
             <id>qa</id>
             <properties>
                    <env>qa</env>
             </properties>
      </profile>
      <profile>
             <id>pre</id>
             <properties>
                    <env>pre</env>
             </properties>
      </profile>
      <profile>
             <id>prod</id>
             <properties>
                    <env>prod</env>
             </properties>
      </profile>
</profiles>
 
......
 
<build>
      <filters>
             <filter>config/${env}.properties</filter>
      </filters>
      <resources>
             <resource>
                    <directory>src/main/resources</directory>
                    <filtering>true</filtering>
             </resource>
      </resources>
 
      ......
 
</build>

​ profiles定义了各个环境的变量 id，filters 中定义了变量配置文件的地址，其中地址中的环境变量就是下面 profile 中定义的值，resources中是定义哪些目录下的文件会被配置文件中定义的变量替换。

​ 通过 maven 能够实现按不同环境进行打包部署，例如：

​ mvn package -Pdev -Dmaven.test.skip=true

​ 示意打包本地环境，并跳过单元测试

IDEA 编辑器集成 Maven 环境

设置 Maven 版本

抉择“File”—>“Other Settings”—>“Settings for New Projects…”—> 搜寻“Maven”

抉择下载好的 maven 版本（目录选到 bin 目录的上一级目录）

设置 settings.xml 文件

设置好之后，抉择“Apply”或者“OK”

Maven 我的项目的创立

创立 Java 我的项目

新建我的项目
  1. 抉择“File”—>“New”—>“Project”
  2. 抉择 ”Maven”，设置 JDK 版本，抉择 maven 我的项目的模板
  3. 设置我的项目的 GroupId 和 ArtifactId
  4. 查看 Maven 环境，抉择“Next”
  5. 查看我的项目名和工作空间，抉择“Finish”
  6. 期待我的项目创立，下载资源，创立实现后目录构造如下

    注：右下角弹出的提示框，抉择“Enable Auto-Import”（Maven 启动主动导入）

编译我的项目
  1. 点击右上角的 “Add Configurations “，关上“Run/Debug Configurations”窗口
  2. 点击左上角的“+”号，抉择“Maven”
  3. 设置编译我的项目的命令
  4. 执行编译命令，两个图标别离代表 ” 一般模式 ” 和 ” 调试模式 ”
  5. 编译胜利

创立 Web 我的项目

创立我的项目
  1. 创立 Web 我的项目与创立 Java 我的项目步骤基本一致，区别在于抉择 Maven 模板（web 项目选择 webapp），如图：
    注：其余步骤与创立一般的 Java 我的项目雷同。
  2. 我的项目目录构造如下：
启动我的项目
批改 JDK 的版本
<!-- JDN 的版本批改为 1.8 -->
<properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
</properties>
设置单元测试的版本
<!-- junit 的版本批改为 4.12 -->
<dependencies>
    <dependency>
        <groupId>junit</groupId>
        <artifactId>junit</artifactId>
        <version>4.12</version>
        <scope>test</scope>
    </dependency>
</dependencies>
删除 pluginManagement 标签
<!-- 将这个标签及标签中的内容全副删除 -->
<pluginManagement>
...
</pluginManagement>
增加 web 部署的插件

​ 在 build 标签中增加 plugins 标签

  1. Jetty 插件

    <!-- 设置在 plugins 标签中 -->
<plugin>
   <groupId>org.mortbay.jetty</groupId>
   <artifactId>maven-jetty-plugin</artifactId>
   <version>6.1.25</version>
   <configuration>
      <!-- 热部署，每 10 秒扫描一次 -->
      <scanIntervalSeconds>10</scanIntervalSeconds>
      <!-- 可指定以后我的项目的站点名 -->
      <contextPath>/test</contextPath>                 
      <connectors>
          <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
              <port>9090</port> <!-- 设置启动的端口号 -->
          </connector>
      </connectors>
   </configuration>
</plugin>

  2. Tomcat 插件

    <!-- 设置在 plugins 标签中 -->
<plugin>
    <groupId>org.apache.tomcat.maven</groupId>
    <artifactId>tomcat7-maven-plugin</artifactId>
    <version>2.1</version>
    <configuration>
        <port>8081</port> <!-- 启动端口 默认:8080 -->
        <path>/test</path> <!-- 我的项目的站点名，即对外拜访门路 -->
        <uriEncoding>UTF-8</uriEncoding> <!-- 字符集编码 默认：ISO-8859-1 -->
        <server>tomcat7</server> <!-- 服务器名称 -->
    </configuration>
</plugin>
启动我的项目
  1. 点击右上角的 “Add Configurations “，关上“Run/Debug Configurations”窗口
  2. 点击左上角的“+”号，抉择“Maven”

  3. Jetty 插件配置

    也能够输出命令指定端口启动

    jetty:run -Djetty.port=9090  # 须要将插件配置中的 port 标签去掉

    点击启动图标，启动服务

    启动胜利
    浏览器拜访成果

  4. Tomcat 插件配置

    启动形式如上，启动胜利

    浏览器拜访 http://localhost:8080/test

  • Maven 依赖仓库：

    ​ https://mvnrepository.com/

  • Tomcat7 插件的命令：

    ​ https://tomcat.apache.org/mav…

Maven 仓库的基本概念

​ 当第一次运行 Maven 命令的时候，你须要 Internet 链接，因为它须要从网上下载一些文件。那么它从哪里下载呢？它是从 Maven 默认的近程库下载的。这个近程仓库有 Maven 的外围插件和可供下载的 jar 文件。

​ 对于 Maven 来说，仓库只分为两类：本地仓库和近程仓库。

​ 当 Maven 依据坐标寻找构件的时候，它首先会查看本地仓库，如果本地仓库存在，则间接应用；如果本地没有，Maven 就会去近程仓库查找，发现须要的构件之后，下载到本地仓库再应用。如果本地仓库和近程仓库都没有，Maven 就会报错。

​ 近程仓库分为三种：地方仓库，私服，其余公共库。

​ 地方仓库是默认配置下，Maven 下载 jar 包的中央。

​ 私服是另一种非凡的近程仓库，为了节俭带宽和工夫，应该在局域网内架设一个公有的仓库服务器，用其代理所有内部的近程仓库。外部的我的项目还能部署到私服上供其余我的项目应用。

​ 一般来说，在 Maven 我的项目目录下，没有诸如 lib/ 这样用来寄存依赖文件的目录。当 Maven 在执行编译或测试时，如果须要应用依赖文件，它总是基于坐标应用本地仓库的依赖文件。

​ 默认状况下，每个用户在本人的用户目录下都有一个路径名为.m2/repository/ 的仓库目录。有时候，因为某些起因（比方 c 盘空间有余）, 须要批改本地仓库目录地址。

​ 对于仓库门路的批改，能够通过 maven 配置文件 conf 目录下 settings.xml 来指定仓库门路

<!-- 设置到指定目录中，门路的斜杆不要写反 -->
<settings>
    <localRepository>D:/m2/repository</localRepository>
</settings>

地方仓库

​ 因为原始的本地仓库是空的，maven 必须晓得至多一个可用的近程仓库，能力执行 maven 命令的时候下载到须要的构件。地方仓库就是这样一个默认的近程仓库。

​ maven-model-builder-3.3.9.jar maven 主动的 jar 中蕴含了一个 超级 POM。定义了默认地方仓库的地位。

地方仓库蕴含了 2000 多个开源我的项目，接管每天 1 亿次以上的拜访。

私服

​ 私服是一种非凡的近程仓库，它是架设在局域网内的仓库服务，私服代理广域网上的近程仓库，供局域网内的 maven 用户应用。当 maven 须要下载构件时，它去私服当中找，如果私服没有，则从内部近程仓库下载，并缓存在私服上，再为 maven 提供。

​ 此外，一些无奈从内部仓库下载的构件也能从本地上传到私服提供局域网中其他人应用

配置形式我的项目 pom.xml 配置

<repositories>
    <repository>
        <snapshots>
            <enabled>true</enabled>
        </snapshots>
        <id>public</id>
        <name>Public Repositories</name>
        <url>http://192.168.0.96:8081/content/groups/public/</url>
    </repository>
    <repository>
        <id>getui-nexus</id>                        <url>http://mvn.gt.igexin.com/nexus/content/repositories/releases/</url>
    </repository>
</repositories>

公司外部应该建设私服：

  • 节俭本人的外网带宽
  • 减速 maven 构建
  • 部署第三方控件
  • 进步稳定性
  • 升高地方仓库的负荷

其余公共库

罕用的阿里云仓库配置

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

Maven 环境下构建多模块我的项目

​ 应用 maven 提供的多模块构建的个性实现 maven 环境下多个模块的我的项目的治理与构建。

这里以四个模块为例来搭建我的项目, 以达到通俗易懂的初衷 

模块 maven_parent —– 基模块, 就是常说的 parent（pom）模块 maven_dao —–  数据库的拜访层，例如 jdbc 操作（jar）模块 maven_service —– 我的项目的业务逻辑层（jar）模块 maven_controller —– 用来接管申请，响应数据（war）

创立 maven_parent 我的项目

  1. 抉择 File —> Settings —> Project
  2. 设置 GroupId 和 ArtifactId
  3. 设置项目名称及工作空间

创立 maven_dao 模块

  1. 抉择我的项目 maven_parent，右键抉择 New，抉择 Module
  2. 抉择 Maven 我的项目的模板（一般 Java 我的项目）
  3. 设置子模块的的 ArtifactId
  4. 设置 Maven 的配置
  5. 设置子模块的名称及寄存地位

创立 maven_service 模块

​ 创立 maven_service 模块的步骤与 maven_dao 模块统一。

建 maven_controller 模块

​ 创立 maven_service 模块的步骤与 maven_dao 模块基本一致，只须要将第一步抉择 Maven 模板设置为 web 我的项目即可。（模板类型：maven-archetype-webapp）

​ 模块全副创立结束后，成果如下：

批改模块的配置

  • 设置 JDK 版本
  • 单元测试 JUnit 版本
  • 删除多余的配置

设置模块之间的依赖

maven_dao
  1. 新建包
  2. 在包中创立 UserDao 类

  3. 在类中增加办法

    package com.xxxx.dao;

public class UserDao {public static void testDao() {System.out.println("UserDao Test...");
    }
}
maven_service

  1. 增加 maven_dao 的依赖

    <!-- 退出 maven_dao 模块的依赖 -->
<dependency>
    <groupId>com.xxxx</groupId>
    <artifactId>maven_dao</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

  2. 在我的项目中增加 UserService 类，并增加办法

    package com.xxxx.service;

import com.xxxx.dao.UserDao;

public class UserService {public static void testService() {System.out.println("UserService Test...");
        // 调用 UserDao 的办法
        UserDao.testDao();}

}
maven_controller

  1. 增加 maven_service 模块的依赖

    <!-- 退出 maven_service 模块的依赖 -->
<dependency>
    <groupId>com.xxxx</groupId>
    <artifactId>maven_service</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

  2. 增加 Servlet 的依赖

    <!-- Servlet 的依赖 -->
<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.0.1</version>
    <scope>provided</scope>
</dependency>

  3. 新建 Java 类，继承 HttpServlet 类，并重写 service 办法

    package com.xxxx.controller;
import com.xxxx.service.UserService;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet("/user")
public class UserServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {System.out.println("UserServlet Test...");
        // 调用 UserService 层的办法
        UserService.testService();}
}

  4. 增加 Tomcat 插件

    <!-- 增加插件 -->
<plugins>
    <!-- tomcat7 插件 -->
    <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.1</version>
        <configuration>
            <!-- <port>8080</port> -->
            <path>/web</path>
            <uriEncoding>UTF-8</uriEncoding>
            <server>tomcat7</server>
        </configuration>
    </plugin>
</plugins>
  5. 启动我的项目
  6. 拜访我的项目

    拜访地址：http://localhost:8080/web/user

    拜访后果：

  7. 如果启动失败，请先将父我的项目 install

    注：如果父我的项目 install 失败，则先将所有子模块 install 胜利后，再 install 父我的项目。

Maven 的打包操作

​ 对于企业级我的项目，无论是进行本地测试，还是测试环境测试以及最终的我的项目上线，都会波及我的项目的打包操作。对于每个环境下的我的项目打包，对应的我的项目所须要的配置资源都会有所区别，实现打包的形式有很多种，能够通过 ant，或者通过 idea 自带的打包性能实现我的项目打包，但当我的项目很大并且须要的外界配置很多时，此时打包的配置就会异样简单，对于 maven 我的项目，咱们能够用过 pom.xml 配置的形式来实现打包时的环境抉择，相比拟其余模式打包工具，通过 maven 只须要通过简略的配置，就能够轻松实现不同环境下我的项目的整体打包。

​ 比方上面这样一个我的项目，我的项目中配置了不同环境下我的项目所须要的配置文件，这时候须要实现不同环境下的打包操作，此时通过批改 pom.xml 如下：

建设对应的目录构造

​ 应用 idea 创立我的项目，目录构造可能会缺失，须要通过手动增加对应的目录。

  1. 增加 Java 源文件夹

    抉择我的项目的 main 文件夹，右键抉择 New，抉择 Directory

    输出文件夹名“Java”，如图：

    抉择 java 目录，右键抉择 Mark Directory as，抉择 Sources Root。将文件夹标记为源文件夹。

  2. 增加资源文件夹

    步骤如上，创立文件夹，命名为 resources，并标记为 Resources Root

  3. 增加对应的文件夹目录，及增加不同环境下对应的配置文件。（本地环境、测试环境、正式环境）

增加 Profile 配置

<!-- 打包环境配置 开发环境 测试环境 正式环境 -->
<profiles>
    <profile>
        <id>dev</id>
        <properties>
            <env>dev</env>
        </properties> 
        <!-- 未指定环境时，默认打包 dev 环境 -->
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <profile>
        <id>test</id>
        <properties>
            <env>test</env>
        </properties>
    </profile>
    <profile>
        <id>product</id>
        <properties>
            <env>product</env>
        </properties>
    </profile>
</profiles>

设置资源文件配置

<!-- 对于我的项目资源文件的配置放在 build 中 -->
<resources>
    <resource>
        <directory>src/main/resources/${env}</directory>
    </resource>
    <resource>
        <directory>src/main/java</directory>
        <includes>
            <include>**/*.xml</include>
            <include>**/*.properties</include>
            <include>**/*.tld</include>
        </includes>
        <filtering>false</filtering>
    </resource>
</resources>

执行打包操作

关上 Run/Debug Configuarations 窗口，输出对应的打包命令

此时对应打包命令

1. `clean compile package -Dmaven.test.skip=true`

​ 打包默认环境（开发环境）并且跳过 maven 测试操作

2. `clean compile package -Ptest -Dmaven.test.skip=true`

​ 打包测试环境并且跳过 maven 测试操作

3. `clean compile package -Pproduct -Dmaven.test.skip=true`

​ 打包生产环境并且跳过 maven 测试操作

打包胜利

不同的我的项目打包的文件不一样，一般来说，一般 java 我的项目打成 jar 包，web 我的项目打成 war 包

Maven 依赖的基本概念

依赖的根本配置

​ 根元素 project 下的 dependencies 能够蕴含多个 dependence 元素，以申明多个依赖。每个依赖都应该蕴含以下元素：

  1. groupId, artifactId, version : 依赖的根本坐标，对于任何一个依赖来说，根本坐标是最重要的，Maven 依据坐标能力找到须要的依赖。
  2. Type：依赖的类型，大部分状况下不须要申明。默认值为 jar

  3. Scope：依赖范畴（compile,test,provided,runtime,system）

    • compile: 编译依赖范畴。

      如果没有指定，就会默认应用该依赖范畴。应用此依赖范畴的 Maven 依赖，对于编译、测试、运行三种 classpath 都无效。

    • test: 测试依赖范畴。

      应用此依赖范畴的 Maven 依赖，只对于测试 classpath 无效，在编译主代码或者运行我的项目的应用时将无奈应用此类依赖。典型的例子就是 JUnit，它只有在编译测试代码及运行测试的时候才须要。

    • provided: 已提供依赖范畴。

      应用此依赖范畴的 Maven 依赖，对于编译和测试 classpath 无效，但在运行时有效。典型的例子是 servlet-api，编译和测试项目的时候须要该依赖，但在运行我的项目的时候，因为容器曾经提供，就不须要 Maven 反复地引入一遍(如：servlet-api)。

    • runtime: 运行时依赖范畴。

      应用此依赖范畴的 Maven 依赖，对于测试和运行 classpath 无效，但在编译主代码时有效。典型的例子是 JDBC 驱动实现，我的项目主代码的编译只须要 JDK 提供的 JDBC 接口，只有在执行测试或者运行我的项目的时候才须要实现上述接口的具体 JDBC 驱动。

    • system: 零碎依赖范畴。

      该依赖与三种 classpath 的关系，和 provided 依赖范畴完全一致。然而，应用 system 范畴依赖时必须通过 systemPath 元素显式地指定依赖文件的门路。因为此类依赖不是通过 Maven 仓库解析的，而且往往与本机系统绑定，可能造成构建的不可移植，因而应该审慎应用。

  4. Optional：标记依赖是否可选
  5. Exclusions：用来排除传递性依赖。

依赖范畴

​ 首先须要晓得，Maven 在编译我的项目主代码的时候须要应用一套 classpath。比方：编译我的项目代码的时候须要用到 spring-core, 该文件以依赖的形式被引入到 classpath 中。其次，Maven 在执行测试的时候会应用另外一套 classpath。如：junit。

​ 最初在理论运行我的项目时，又会应用一套 classpath，spring-core 须要在该 classpath 中，而 junit 不须要。

​ 那么依赖范畴就是用来管制依赖与这三种 classpath(编译 classpath，测试 classpath，运行时 classpath)的关系，Maven 有以下几种依赖范畴：

  • Compile 编译依赖范畴。如果没有指定，就会默认应用该依赖范畴。应用此依赖范畴的 Maven 依赖，对于编译，测试，运行都无效。
  • Test：测试依赖范畴。只在测试的时候须要。比方 junit
  • Provided：已提供依赖范畴。应用此依赖范畴的 Maven 依赖，对于编译和测试无效，但在运行时有效。典型的例子是 servlet-API, 编译和测试项目的须要，但在运行我的项目时，因为容器曾经提供，就不须要 Maven 反复地引入一遍。
  • Runtime：运行时依赖范畴。应用此依赖范畴的 Maven 依赖，对于测试和运行无效，但在编译代码时有效。典型的例子是：jdbc 驱动程序，我的项目主代码的编译只须要 jdk 提供的 jdbc 接口，只有在执行测试或者运行我的项目的时候才须要实现上述接口的具体 jdbc 驱动。
  • System：零碎依赖范畴。个别不应用。

传递性依赖

​ 传递依赖机制，让咱们在应用某个 jar 的时候就不必去思考它依赖了什么。也不必放心引入多余的依赖。Maven 会解析各个间接依赖的 POM，将那些必要的间接依赖，以传递性依赖的模式引入到以后我的项目中。

​ 留神：传递依赖有可能产生抵触！！

抵触场景：

A-->B--->C (2.0)

A-->E--->C (1.0)

​ 如果 A 下同时存在两个不同 version 的 C，抵触！！（选取同时适宜 A、B 的版本）

<dependencies>  
    <dependency>  
        <groupId>A</groupId>  
        <artifactId>A</artifactId>  
        <version>xxx</version>  
        <exclusions>  
            <exclusion>  
                <groupId>C</groupId>  
                <artifactId>C</artifactId> 
            </exclusion>  
        </exclusions>  
    </dependency> 

    <dependency>  
        <groupId>B</groupId>  
        <artifactId>B</artifactId>              
    </dependency>  
</dependencies>
退出移动版