maven POM配置学习笔记

最新推荐文章于 2024-03-25 17:32:38 发布

yezhirm7

最新推荐文章于 2024-03-25 17:32:38 发布

阅读量549

点赞数

分类专栏：开发工具文章标签： POM Maven 配置

本文链接：https://blog.csdn.net/yezhirm7/article/details/100539660

版权

开发工具专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Maven & POM

Maven是一个项目管理和综合工具。Maven提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设，Maven使用标准的目录结构和默认构建生命周期。
在多个开发团队环境时，Maven可以设置按标准在非常短的时间里完成配置工作。由于大部分项目的设置都很简单，并且可重复使用，Maven让开发人员的工作更轻松，同时创建报表，检查，构建和测试自动化设置。
Apache Maven 是一种创新的软件项目管理工具，提供了一个项目对象模型（POM）文件的新概念来管理项目的构建，相关性和文档。最强大的功能就是能够自动下载项目依赖库。
POM stands for “Project Object Model”. It is an XML representation of a Maven project held in a file named pom.xml.
POM代表“项目对象模型”，是Maven项目的XML形式，保存在pom.xml文件。
官网上POM的定义：The POM contains all necessary information about a project, as well as configurations of plugins to be used during the build process. It is, effectively, the declarative manifestation of the “who”, “what”, and “where”, while the build lifecycle is the “when” and “how”.
POM包含关于项目的所有必要信息，以及在构建过程中使用的插件的配置。它实际上是“谁”、“什么”和“在哪里”的声明性表示，而构建生命周期是“何时”和“如何”。

The Basics

groupId，artifactId，version
所有 POM 文件都需要 project 元素和三个必需字段：groupId，artifactId，version。（如果groupId和version是从父类继承的，则不需要显式定义它们）

<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>
    <!-- 公司或者组织的唯一标志，并且配置时生成的路径也是由此生成， 如com.XXX.YYY，maven会将该项目打成的jar包放本地路径：/com/XXX/YYY -->
    <groupId>com.companyname.project-group</groupId>
    <!-- 项目的唯一ID，一个groupId下面可能多个项目，就是靠artifactId来区分的 -->
    <artifactId>project</artifactId>
    <!-- 版本号 -->
    <version>1.0</version>
</project>

Packaging

<packaging>war</packaging>

项目打包成war格式，设置打包机制，如pom,jar,maven-plugin,ejb,war,ear,rar,par

Super POM
父（Super）POM是 Maven 默认的 POM。所有的 POM 都继承自一个父 POM（无论是否显式定义了这个父 POM）。父 POM 包含了一些可以被继承的默认设置。因此，当 Maven 发现需要下载 POM 中的依赖时，它会到 Super POM 中配置的默认仓库去下载，父POM帮助开发者在 pom.xml 中做尽可能少的配置，当然这些配置可以被重写。
Properties
properties为pom定义一些常量，在pom中的其它地方可以直接引用，使用方式为 ${flink.version}，

<properties>
        <spark.scope>x</spark.scope>
        <mybatis.spring.boot.version>x.x</mybatis.spring.boot.version>
       <flink.version>x.x</flink.version>
 </properties>

dependencyManagement
一般只出现在父pom里面，用于帮助管理子POM的dependencies，统一版本号。dependencyManagement下面所依赖的jar包，不会被子项目所依赖（仅仅是管理版本），但是可以管理children所依赖的版本
Dependencies

<dependencies>
<dependency>
<! groupId、artifactId、version确定所依赖的项目-->
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.88</version>
<! 依赖类型，默认类型是jar。它通常表示依赖的文件的扩展名，但也有例外。一个类型可以被映射成另外一个扩展名或分类器。-->
      <type>jar</type>
      <!--依赖范围-->
      <scope>test</scope>
<!--仅供system范围使用。注意，不鼓励使用这个元素，并且在新的版本中该元素可能被覆盖掉。该元素为依赖规定了文件系统上的路径。需要绝对路径而不是相对路径。推荐使用属性匹配绝对路径，例如${java.home}。 -->
      <systemPath></systemPath>
      <!--当计算传递依赖时， 从依赖构件列表里，列出被排除的依赖构件集。即告诉maven你只依赖指定的项目，不依赖项目的依赖。此元素主要用于解决版本冲突问题 -->
       <exclusions>
                <exclusion>
                    <artifactId>spring-core</artifactId>
                    <groupId>org.springframework</groupId>
                </exclusion>
       </exclusions>
      <!--可选依赖，设置指依赖是否可选，默认为false,即子项目默认都继承。如果你在项目B中把C依赖声明为可选，你就需要在依赖于B的项目（例如项目A）中显式的引用对C的依赖。可选依赖阻断依赖的传递性。 -->
      <optional>true</optional>
    </dependency>
    ……
  </dependencies>

Scope：
此元素引用当前任务的类路径(编译和运行时、测试等)，以及如何限制依赖项的传递性。有五种适用范围:

compile编译——这是默认范围，如果没有指定，就使用它。编译依赖项在所有类路径中都可用。此外，这些依赖项将传递到依赖的项目。
provided提供——这很像编译，但表明您希望JDK或容器在运行时提供它。它只在编译和测试类路径上可用，并且不能传递。
runtime运行时——这个范围表明编译不需要依赖项，但是执行需要依赖项。它位于运行时和测试类路径中，但不在编译类路径中。
test—这个范围表明依赖项对于应用程序的正常使用不是必需的，并且只在测试编译和执行阶段可用。它不是传递的。
system系统——这个范围与provided类似，只是您必须显式地提供包含它的JAR。总是可用的，并且不会在存储库中查找。
依赖关系
依赖传递
A–>B–>C。当前项目为A，A依赖于B，B依赖于C
如果C的scope是test或者provided时，C直接被丢弃，A不依赖C；否则A依赖C。
依赖仲裁
最短路径原则：
A->B->C->common1.1.jar
结果：A->common1.0.jar
加载先后原则：
A->B， B->common1.0.jar
A->C，C->common1.1.jar
A同时依赖B和C，那么B和C谁先加载，就依赖谁的common.jar
Optional& Exclusion
可选依赖（Optional Dependencies）用在不能真正地将一个项目划分为多个子模块时。一些依赖只在该项目中的某些特性中使用,
并且如果这些特性没有使用到的话, 这些依赖就不需要。最理想的情况, 这样的特性会被划分到一个依赖于核心功能工程的子模块,
这个新子模块将只有非可选依赖, 因为一旦你决定使用该子模块的功能, 你就会需要这些依赖。然而, 如果该项目无法划分,
这些依赖就需要被声明为可选的。如果一个用户想要使用和一个可选依赖相关的功能，他们需要在自己的工程里声明那个可选依赖。
例如：X依赖A，A依赖B用的true，这时B只能在A中使用，而不会主动传递到X中，X需要主动引用B才有B的依赖。
如果A不用true引用B，则会传递到X中，X如果不需要B则需要主动排除A传递过来的B。
配置可选依赖的原因：1、节约磁盘、内存等空间；2、避免license许可问题；3、避免类路径问题等等。
Exclusion 是maven2.x提出的依赖排除概念. 排除是针对POM中的一个特定的依赖设置的,
以一个特定的groupId和artifactId为标识. 如果你声明了排除依赖, 当你构建你的工程时,
该构件就不会被添加到你的工程的类路径中.例如：当一个项目A依赖项目B，而项目B同时依赖项目C，如果项目A中因为各种原因不想引用项目C，在配置项目B的依赖时，可以排除对C的依赖。

Build标签
build标签描述了如何来编译及打包项目，而具体的编译和打包工作是通过build中配置的 plugin 来完成
官网描述build标签：According to the POM 4.0.0 XSD, the build element is conceptually divided into two parts: there is a BaseBuild type which contains the set of elements common to both build elements (the top-level build element under project and the build element under profiles, covered below); and there is the Build type, which contains the BaseBuild set as well as more elements for the top level definition. Let us begin with an analysis of the common elements between the two.
根据POM 4.0.0 XSD，build元素在概念上分为两部分:有一个BaseBuild type，它包含两个build元素的公共元素集(project下的顶层build元素和profiles文件下的build元素);还有一个是build type，它包含BaseBuild set以及用于顶层定义的更多元素。
注意:
一种被称为Project Build，即是的直接子元素。
另一种被称为Profile Build，即是的直接子元素。
Profile Build包含了基本的build元素，而Project Build还包含两个特殊的元素，即各种<…Directory>和。

The BaseBuild Element Set
POM中两个build元素之间的基本元素集。

<build>
    <defaultGoal>install</defaultGoal>
    <directory>${basedir}/target</directory>
    <finalName>${artifactId}-${version}</finalName>
    <filters>
       <filter>filters/filter1.properties</filter>
    </filters>
  ...
</build>

defaultGoal
执行构建时默认的goal或phase，如jar:jar或者package等, 比如defaultGoal 设置为install，你想要执行mvn install ，那么直接打命令mvn，就可以了。
directory
构建工程之后，工程的输出目录。
finalName
构建的最终结果的名字，finalName可能在其他plugin中被改变。
filters
给出对资源文件进行过滤的属性文件的路径，默认位于${basedir}/src/main/filters/目录下。属性文件中定义若干了键值对，用于在构建过程中将资源文件中出现的变量（键）替换为对应的值。

resources
资源往往不是代码，无需编译，而是一些properties或XML配置文件，构建过程中会往往会将资源文件从源路径复制到指定的目标路径。给出各个资源在Maven项目中的具体路径。

<resources>
      <resource>
        <targetPath>META-INF/plexus</targetPath>
        <filtering>false</filtering>
        <directory>${basedir}/src/main/plexus</directory>
        <includes>
          <include>configuration.xml</include>
        </includes>
        <excludes>
          <exclude>**/*.properties</exclude>
        </excludes>
      </resource>
    </resources>
    <testResources>
      ...
    </testResources>

targetPath
指定放置构建过程的资源集的目录结构。目标路径默认为基本目录。将打包在JAR中的资源的通常指定的目标路径是META-INF。
filtering
表示是否为该资源启用过滤，默认false
directory
定义要在何处找到资源。构建默认目录是 ${basedir}/src/main/resources。 include 一组文件的模式，指定包含的文件作为该指定目录下的资源。 exclude 与include相同的结构，但指定忽略哪些文件。当include和exclude之间冲突，exclude优先。 testResources 定义类似于资源元素，test过程中涉及的资源文件，默认位于$ {basedir}/src/test/resources/目录下。这里的资源文件不会被构建到目标构件中。

pluginManagement
在中，与并列，两者之间的关系类似于与之间的关系。中也配置，其配置参数与中的完全一致。只是，往往出现在父项目中，其中配置的往往通用于子项目。子项目中只要在中以声明该插件，该插件的具体配置参数则继承自父项目中对该插件的配置，从而避免在子项目中进行重复配置。子项目可以重写pluginManagement 的定义。（The children have every right to override pluginManagement definitions.）
plugins
给出构建过程中所用到的插件。

<plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>
        <version>x.x</version>
        <extensions>false</extensions>
        <inherited>true</inherited>
        <configuration>
          <classifier>test</classifier>
        </configuration>
        <dependencies>...</dependencies>
        <executions>...</executions>
      </plugin>
    </plugins>

Extensions
是否加载该插件的扩展，默认false
Inherited
该插件的configuration中的配置是否可以被（继承该POM的其他Maven项目）继承，默认true。
Configuration
这是特定于单个插件的。在不深入了解插件如何工作的机制的情况下，只需说明Mojo插件可能期望的任何属性都可以在这里指定(这些属性是Java Mojo bean中的getter和setter)。在上面的例子中，我们将classifier属性设置为在maven-jar-plugin的Mojo中进行测试。值得注意的是，所有configuration元素，无论它们在POM中的哪个位置，都打算将值传递给另一个底层系统，例如plugin。换句话说:POM模式从来不显式地需要配置元素中的值，但是插件目标完全有权要求配置值。如果您的POM声明了父类，它将从父类的build/plugins或pluginManagement部分继承插件配置
Dependencies
依赖项具有与项目基本构建相同的结构和功能。在这种情况下，主要的区别是，它们不是作为项目的依赖项应用，而是作为它们所在插件的依赖项应用。这一功能的强大之处在于可以更改插件的依赖项列表，方法可能是通过排除来删除未使用的运行时依赖项，或者更改所需dpendency的版本。
Executions
该插件的某个goal（一个插件中可能包含多个goal）的执行方式。一个execution有如下设置：

id，唯一标识
goals，要执行的插件的goal（可以有多个），如run
phase，目标列表执行阶段。这是一个非常强大的选项，允许将任何目标绑定到构建生命周期中的任何阶段，从而改变Maven的默认行为。
inherited，该execution是否可被子项目继承
configuration，与上面相同，但是将配置限制在这个特定的目标列表中，而不是插件下的所有目标。

2. The Build Element Set
Directories
目录元素集位于父构建元素中，父构建元素为POM整体设置了各种目录结构。因为它们不存在于Profile Build中，所以不能被Profile 文件更改。

<build>
    <sourceDirectory>${basedir}/src/main/java</sourceDirectory>
    <testSourceDirectory>${basedir}/src/test/java</testSourceDirectory>
    <outputDirectory>${basedir}/target/classes</outputDirectory>
    <testOutputDirectory>${basedir}/target/test-classes</testOutputDirectory>
    ...
  </build>

extensions
是执行构建过程中可能用到的其他工具，在执行构建的过程中被加入到classpath中。也可以通过激活构建插件，从而改变构建的过程。通常，通过给出通用插件的一个具体实现，用于构建过程。简而言之，扩展是在构建期间激活的构件。扩展实际上不需要做任何事情，也不需要包含Mojo。

<build>
    ...
    <extensions>
      <extension>
        <groupId>org.apache.maven.wagon</groupId>
        <artifactId>wagon-ftp</artifactId>
        <version>1.0-alpha-3</version>
      </extension>
    </extensions>
    ...
  </build>

3. Reporting

<reporting>
    <outputDirectory>${basedir}/target/site</outputDirectory>
    <plugins>
      <plugin>
        <artifactId>maven-project-info-reports-plugin</artifactId>
        <version>2.0.1</version>
        <reportSets>
          <reportSet>
            <id>sunlink</id>
            <reports>
              <report>javadoc</report>
            </reports>
            <inherited>true</inherited>
            <configuration>
              <links>
                <link>http://java.sun.com/j2se/1.5.0/docs/api/</link>
              </links>
            </configuration>
          </reportSet>
        </reportSets>
      </plugin>
    </plugins>
  </reporting>

官网：Reporting contains the elements that correspond specifically for the site generation phase. Certain Maven plugins can generate reports defined and configured under the reporting element, for example: generating Javadoc reports.
报表包含特定于site生成阶段的元素。某些Maven插件可以生成在报表元素下定义和配置的报表，例如:生成Javadoc报表。
在reporting下配置的report plugin的方法与build几乎一样，最不同的是build的plugin goals在executions下设置，而reporting的configures goals在reporttest。

excludeDefaults:是否排除site generator默认产生的reports
outputDirectory:默认的dir变成:${basedir}/target/site
report sets:设置execution goals,相当于build里面的executions,不同的是不能够bind a report to another phase,只能够是site。

More Project Information
Name
项目除了artifactId外，可以定义多个名称
Description
项目描述
url
项目url
inceptionYear
创始年份

Licenses

<licenses>
        <!--描述了项目的license，用于生成项目的web站点的license页面，其他一些报表和validation也会用到该元素。 -->
        <license>
            <!--license用于法律上的名称 -->
            <name>Apache 2</name>
            <!--官方的license正文页面的URL -->
            <url>http://www.baidu.com/banseon/LICENSE-2.0.txt</url>
            <!--项目分发的主要方式： repo，可以从Maven库下载 manual， 用户必须手动下载和安装依赖 -->
            <distribution>repo</distribution>
            <!--关于license的补充信息 -->
            <comments>A business-friendly OSS license</comments>
        </license>
    </licenses>

列出本工程直接的licenses，而不要列出dependencies的licenses。
2. organization

organization>
        <!--组织的全名 -->
        <name>demo</name>
        <!--组织主页的URL -->
        <url>http://www.baidu.com/banseon</url>
    </organization>

Environment Settings
1. Issue Management
这定义了所使用的缺陷跟踪系统(Bugzilla、TestTrack、ClearQuest等)。虽然没有什么可以阻止插件使用这些信息，但是它主要用于生成项目文档。

  <issueManagement>
    <system>Bugzilla</system>
    <url>http://127.0.0.1/bugzilla/</url>
  </issueManagement>

2. Continuous Integration Management

<!--项目持续集成信息 -->
    <ciManagement>
        <!--持续集成系统的名字，例如continuum -->
        <system />
        <!--该项目使用的持续集成系统的URL（如果持续集成系统有web接口的话）。 -->
        <url />
        <!--构建完成时，需要通知的开发者/用户的配置项。包括被通知者信息和通知条件（错误，失败，成功，警告） -->
        <notifiers>
            <!--配置一种方式，当构建中断时，以该方式通知用户/开发者 -->
            <notifier>
                <!--传送通知的途径 -->
                <type />
                <!--发生错误时是否通知 -->
                <sendOnError />
                <!--构建失败时是否通知 -->
                <sendOnFailure />
                <!--构建成功时是否通知 -->
                <sendOnSuccess />
                <!--发生警告时是否通知 -->
                <sendOnWarning />
                <!--不赞成使用。通知发送到哪里 -->
                <address />
                <!--扩展配置项 -->
                <configuration />
            </notifier>
        </notifiers>
    </ciManagement>

3. SCM
SCM(Source Control Management，软件配置管理，也称为源代码/控制管理，或者简单地说是版本控制)标签允许你配置你的代码库，供Maven web站点和其它插件使用。

<scm>
        <!--SCM的URL,该URL描述了版本库和如何连接到版本库。欲知详情，请看SCMs提供的URL格式和列表。该连接只读。 -->
        <connection>
       scm:svn:http://svn.baidu.com/banseon/maven/banseon/banseon-maven2-trunk(dao-trunk)
        </connection>
        <!--开发者使用，类似connection元素。即该连接不仅仅只读 -->
        <developerConnection>
       scm:svn:http://svn.baidu.com/banseon/maven/banseon/dao-trunk
        </developerConnection>
        <!--当前代码的标签，在开发阶段默认为HEAD -->
        <tag />
        <!--指向项目的可浏览SCM库（例如ViewVC）的URL。 -->
        <url>http://svn.baidu.com/banseon</url>
    </scm>

4. Prerequisites
为了正确执行POM，可能有某些先决条件，在Maven 2中，提供了构建的先决条件:如果不满足这些条件，Maven甚至在启动构建之前就会失败。在POM 4.0中，惟一作为先决条件存在的元素是maven元素，它接受最小版本号。在Maven 2中检查的，在Maven 3中不再检查了。

  <prerequisites>
    <maven>2.0.6</maven>
  </prerequisites>

5. Repositories
pom里面的仓库与setting.xml里的仓库功能是一样的。主要的区别在于，pom里的仓库是个性化的。比如一家大公司里的setting文件是公用的，所有项目都用一个setting文件，但各个子项目却会引用不同的第三方库，所以就需要在pom里设置自己需要的仓库地址。
要成为maven2的repository artifact，必须具有pom文件在$BASE_REPO/groupId/artifactId/version/artifactId-version.pom 。
BASE_REPO可以是本地，也可以是远程的。repository元素就是声明那些去查找的repositories 。
默认的central Maven repository在http://repo1.maven.org/maven2/

<repositories>
    <repository>
      <releases>
        <enabled>false</enabled>
        <updatePolicy>always</updatePolicy>
        <checksumPolicy>warn</checksumPolicy>
      </releases>
      <snapshots>
        <enabled>true</enabled>
        <updatePolicy>never</updatePolicy>
        <checksumPolicy>fail</checksumPolicy>
      </snapshots>
      <id>codehausSnapshots</id>
      <name>Codehaus Snapshots</name>
      <url>http://snapshots.maven.codehaus.org/maven2</url>
      <layout>default</layout>
    </repository>
  </repositories>

release和snapshots
是artifact的两种policies，pom可以选择那种政策有效。
Enable
本别指定两种类型是否可用，true or false
updatePolicy
说明更新发生的频率always 或者 never 或者 daily（默认的）或者 interval:X（X是分钟数）
checksumPolicy
当Maven的部署文件到仓库中，它也部署了相应的校验和文件。您可以选择忽略，失败，或缺少或不正确的校验和警告。
Layout
Maven 2引入的布局是Maven 2和Maven 3使用的存储库的默认布局;然而maven1.x与maven2有不同的layout，所以可以声明为default或者是legacy（遗留方式maven1.x）。
6. Plugin Repositories
与Repositories具有类似的结构，只是Repositories是dependencies的库，而这个是plugins 的库。
7. Distribution Management
发行管理就像它听起来的那样:它管理工件的发行以及在整个构建过程中生成的支持文件。

  <distributionManagement>
    ...
    <downloadUrl>http://mojo.codehaus.org/my-project</downloadUrl>
    <status>deployed</status>
  </distributionManagement>

downloadUrl
是其他项目为了抓取本项目的pom’s artifact而指定的url，就是说告诉pom upload的地址也就是别人可以下载的地址。
Status
这里的状态不要受到我们的设置，maven会自动设置project的状态，有效的值：

none：没有声明状态，pom默认的；
converted:本project是管理员从原先的maven版本convert到maven2的；
partner：以前叫做synched，意思是与partner repository已经进行了同步；
deployed：至今为止最经常的状态，意思是制品是从maven2 instance部署的，人工在命令行deploy的就会得到这个；
verified：本制品已经经过验证，也就是已经定下来了最终版。

Repository
官网说明：Whereas the repositories element specifies in the POM the location and manner in which Maven may download remote artifacts for use by the current project, distributionManagement specifies where (and how) this project will get to a remote repository when it is deployed. The repository elements will be used for snapshot distribution if the snapshotRepository is not defined.
尽管repositories元素在pom中指定了maven可以下载远程工件以供当前项目使用的位置和方式，但是distributionmanagement指定了部署此项目时该项目将在何处（以及如何）到达远程存储库。如果未定义SnapshotRepository，则存储库元素将用于Snapshot分发。
简而言之，声明部署（deployed）过程中当前工程（current project）会如何变成repository，说明部署到repository的信息。

 <distributionManagement>
    <repository>
      <uniqueVersion>false</uniqueVersion>
      <id>corp1</id>
      <name>Corporate Repository</name>
      <url>scp://repo/maven2</url>
      <layout>default</layout>
    </repository>
    <snapshotRepository>
      <uniqueVersion>true</uniqueVersion>
      <id>propSnap</id>
      <name>Propellors Snapshots</name>
      <url>sftp://propellers.net/maven</url>
      <layout>legacy</layout>
    </snapshotRepository>
    ...
  </distributionManagement>

id, name:唯一性的id，和可读性的name
uniqueVersion：指定是否产生一个唯一性的version number还是使用address里的其中version部分。true or false
url：说明location和transport protocol
layout：default或者legacy
site
除了分发到存储库之外，DistributionManagement还负责定义如何部署项目的站点和文档。（More than distribution to the repositories, distributionManagement is responsible for defining how to deploy the project’s site and documentation.）

<distributionManagement>
    <site>
      <id>mojo.website</id>
      <name>Mojo Website</name>
    <url>scp://beaver.codehaus.org/home/projects/mojo/public_html/</url>
    </site>
  </distributionManagement>

id、name、url：这些元素与上面在distributionmanagement repository元素中的对应元素类似。
Relocation（迁徙）
Projects are not static; they are living things. A common thing that happens as projects grow, is that they are forced to move to more suitable quarters. For example, when your next wildly successful open source project moves under the Apache umbrella, it would be good to give users a heads-up that the project is being renamed to org.apache:my-project:1.0. Besides specifying the new address, it is also good form to provide a message explaining why.
项目不是静止的，它们是有生命的东西。随着项目的发展，一个常见的现象是他们被迫搬到更合适的地方。例如，当您的下一个非常成功的开源项目转移到Apache保护伞下时，最好提醒用户该项目将被重命名为org.apache:my project:1.0。除了指定新地址之外，还可以提供一条消息来解释原因。

 <distributionManagement>
    <relocation>
      <groupId>org.apache</groupId>
      <artifactId>my-project</artifactId>
      <version>1.0</version>
      <message>We have moved the Project under Apache</message>
    </relocation>
  </distributionManagement>

8. Profiles
官网说明：A new feature of the POM 4.0 is the ability of a project to change settings depending on the environment where it is being built. A profile element contains both an optional activation (a profile trigger) and the set of changes to be made to the POM if that profile has been activated. For example, a project built for a test environment may point to a different database than that of the final deployment. Or dependencies may be pulled from different repositories based upon the JDK version used.
POM4.0的一个新特性是，项目能够根据其构建环境更改设置。配置文件元素包含一个可选的激活（配置文件触发器）和一组要对POM进行的更改（如果该配置文件已被激活）。例如，为测试环境构建的项目可能指向与最终部署不同的数据库，或者可以根据使用的jdk版本从不同的存储库中提取依赖项。

<profiles>
    <profile>
      <id>test</id>
      <activation>...</activation>
     <!--构建项目所需要的信息。参见build元素 -->
      <build>...</build>
      <modules>...</modules>
<!--参见repositories/repository元素 -->
      <repositories>...</repositories>
<!--参见plugin元素 -->
      <pluginRepositories>...</pluginRepositories>
      <dependencies>...</dependencies>
      <reporting>...</reporting>
      <dependencyManagement>...</dependencyManagement>
      <distributionManagement>...</distributionManagement>
    </profile>
  </profiles>

activation是profile的关键。概要文件的威力来自它仅在特定情况下修改基本POM的能力。这些情况是通过activation元素指定的。

<activation>
        <activeByDefault>false</activeByDefault>
        <jdk>1.5</jdk>
        <os>
          <name>Windows XP</name>
          <family>Windows</family>
          <arch>x86</arch>
          <version>5.1.2600</version>
        </os>
        <property>
          <name>sparrow-type</name>
          <value>African</value>
        </property>
        <file>
          <exists>${basedir}/file2.properties</exists>
          <missing>${basedir}/file1.properties</missing>
        </file>
      </activation>

当满足一个或多个指定条件时，将发生激活profile。

jdk: Java核心版本
os: 操作系统相关属性
property:如果Maven检测到对应的name=value对的属性(可以在POM中通过${name}取消引用的值)，则配置文件将被激活。
file:给定的文件名可能会因为文件的存在或缺少文件而激活配置文件。注意:此元素的内插仅限于${basedir}、系统属性和请求属性。
激活profile的方法有多个：setting文件的activeProfile元素明确指定激活的profile的ID，在命令行上明确激活Profile用-P flag 参数。查看某个build会激活的profile列表可以用：mvn help:active-profiles。

参考链接
https://www.cnblogs.com/qq78292959/p/3711501.html
https://blog.csdn.net/q979076061/article/details/74178186
https://blog.csdn.net/u010010606/article/details/79727438
https://www.cnblogs.com/1si2/p/maven_filter.html
https://www.runoob.com/maven/maven-pom.html
http://maven.apache.org/pom.html#Prerequisites

yezhirm7

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
maven POM配置学习笔记

Maven & POMMaven是一个项目管理和综合工具。Maven提供了开发人员构建一个完整的生命周期框架。开发团队可以自动完成项目的基础工具建设，Maven使用标准的目录结构和默认构建生命周期。在多个开发团队环境时，Maven可以设置按标准在非常短的时间里完成配置工作。由于大部分项目的设置都很简单，并且可重复使用，Maven让开发人员的工作更轻松，同时创建报表，检查，构建和测试自...
复制链接

扫一扫

专栏目录