前言
当咱们在开发我的项目时，有时须要用到内部依赖组件，例如当咱们须要Json序列化的时候须要用到FastJson组件，咱们能够通过下载对应jar包加载到我的项目中。但当一个大的我的项目同时须要依赖各种各样的内部服务，就存在着配置繁琐、依赖抵触等问题，因而能够通过maven来实现对应的依赖治理性能。
一、Settings配置
settings.xml用来配置maven我的项目中的各种参数文件，包含本地仓库、近程仓库、私服、认证等信息。
1.1 配置概述
1.1.1 全局settings、用户setting、pom的区别
- 全局 settings.xml 是 maven 的全局配置文件，个别位于${maven.home}/conf/settings.xml，即maven文件夹下的conf中。
- 用户 setting是maven的用户配置文件，个别位于${user.home}/.m2/settings.xml，即每位用户都有一份配置文件。
- pom.xml 文件是我的项目配置文件，个别位于我的项目根目录下或子目录下。
配置优先级从高到低：pom.xml > 本地 settings > 全局 settings
如果这些文件同时存在，在利用配置时，会合并它们的内容，如果有反复的配置，优先级高的配置会笼罩优先级低的。
1.1.2 仓库【重要】
如前言所述，咱们依赖的内部服务是须要有中央进行存储的，而存储的中央就称之为仓库。其中仓库又分为本地仓库、地方仓库、镜像仓库、私服。
其对应关系为：
（1）本地仓库
当我的项目在本地编译或运行时，间接加载本地的依赖服务无疑是最快的。默认状况下，不论在Window还是Linux下，每个用户在本人用户目录下都有一个路径名为.m2/repository/的仓库目录。
而原始的本地仓库是为空的，因而maven须要晓得一个网络上的仓库，在本地仓库不存在时返回下载网络上的仓库，也就是近程仓库。
（2）地方仓库
当maven未配置时，会默认申请maven的地方仓库，地方仓库蕴含了这个世界上绝大多数风行的开源java构件，以及源码、作者信息、SCM,信息、许可证信息等，每个月这里都会承受全世界java程序员大略1亿次的拜访，它对全世界java开发者的奉献由此可见一斑。
然而因为最常见的例如网络起因等，国外的地方仓库应用起来并不顺利，因而就有了下载地址为国内的地方仓库，也就是镜像仓库。
（3）镜像仓库
总结来说，镜像仓库就是将国外的核心仓库复制一份到国内，这样一来下载速度以及访问速度都将很快。
（4）私服
一般来说地方仓库或者镜像仓库都能满足咱们的需要，然而当咱们在公司内合作开发代码时，可能因为零碎保密性起因，有一些其余共事开发的内部依赖只心愿可能被本公司的人应用，而如果上传到镜像仓库则保密性就不复存在了。因而私服最次要的性能时存储一些公司外部不心愿被公开的依赖服务。
1.2 settings配置详解
settings.xml配置了本地全局maven的相干配置。
以下是一份seetings.xml的文件配置顶级元素。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository> <interactiveMode> <usePluginRegistry> <offline> <pluginGroups> <servers> <mirrors> <proxies> <profiles> <activeProfiles></settings>1.2.1 localRepository
用来标识本地仓库的地位
D:/Maven/Repository1.2.2 interactiveMode
maven 是否须要和用户交互以取得输出。默认为true。
true1.2.3 usePluginRegistry
maven 是否须要应用 plugin-registry.xml 文件来治理插件版本。
false1.2.4 offline
用来标识是否以离线模式经营maven。
当零碎不能联网时，能够通过次配置来离线运行。
false1.2.5 servers
当应用maven私服时，某些私服须要配置认证信息，须要在此处填写相应的配置。之所以不写在pom.xml中是因为个别我的项目在上传至代码仓库时同样会将pom.xml上传，而setting.xml个别位于用户本地，因而绝对比拟平安。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <!--配置服务端的一些设置。一些设置如平安证书不应该和pom.xml一起散发。这种类型的信息应该存在于构建服务器上的settings.xml文件中。 --> <servers> <!--服务器元素蕴含配置服务器时须要的信息 --> <server> <!--这是server的id（留神不是用户登陆的id），该id与distributionManagement中repository元素的id相匹配。 --> <id>server001</id> <!--鉴权用户名。鉴权用户名和鉴权明码示意服务器认证所须要的登录名和明码。 --> <username>my_login</username> <!--鉴权明码 。鉴权用户名和鉴权明码示意服务器认证所须要的登录名和明码。明码加密性能已被增加到2.1.0 +。详情请拜访明码加密页面 --> <password>my_password</password> <!--鉴权时应用的私钥地位。和前两个元素相似，私钥地位和私钥明码指定了一个私钥的门路（默认是${user.home}/.ssh/id_dsa）以及如果需要的话，一个密语。未来passphrase和password元素可能会被提取到内部，但目前它们必须在settings.xml文件以纯文本的模式申明。 --> <privateKey>${usr.home}/.ssh/id_dsa</privateKey> <!--鉴权时应用的私钥明码。 --> <passphrase>some_passphrase</passphrase> <!--文件被创立时的权限。如果在部署的时候会创立一个仓库文件或者目录，这时候就能够应用权限（permission）。这两个元素非法的值是一个三位数字，其对应了unix文件系统的权限，如664，或者775。 --> <filePermissions>664</filePermissions> <!--目录被创立时的权限。 --> <directoryPermissions>775</directoryPermissions> </server> </servers> ...</settings>1.2.6 mirrors【重要】
用来配置相应的镜像仓库。
如果仓库X能够提供仓库Y存储的所有内容，那么就能够认为X是Y的一个镜像。用过Maven的都晓得，国外的地方仓库因为网络起因用起来太慢了，所以抉择一个国内的镜像就很有必要，配置简略，批改conf文件夹下的settings.xml文件，增加如下镜像配置：
<mirrors> <mirror> <id>alimaven</id> <name>aliyun maven</name> <url>http://maven.aliyun.com/nexus/content/groups/public/</url> <mirrorOf>central</mirrorOf> </mirror> <mirror> <id>alimaven1</id> <name>aliyun maven1</name> <url>http://maven.aliyun.com/nexus/content/groups/public/</url> <mirrorOf>*</mirrorOf> </mirror></mirrors>其中id与name用来标识惟一的仓库，url为镜像仓库地址，mirrorOf用来匹配当申请什么仓库依赖时应用该镜像。
这里介绍下<mirrorOf>配置的各种选项
<mirrorOf>*<mirrorOf>:匹配所有近程仓库。<mirrorOf>external:*<mirrorOf>:匹配所有近程仓库，应用localhost的除外，应用file://协定的除外。也就是说，匹配所有不在本机上的近程仓库。<mirrorOf>repo1,repo2<mirrorOf>:匹配仓库repo1h和repo2，应用逗号分隔多个近程仓库。<mirrorOf>*,!repo1<mirrorOf>:匹配所有近程仓库，repo1除外，应用感叹号将仓库从匹配中排除。
须要留神的是，因为镜像仓库齐全屏蔽了被镜像仓库，当镜像仓库不稳固或者进行服务的时候，Maven仍将无法访问被镜像仓库，因此将无奈下载构件。
此外， maven 读取mirror 配置是 从上往下读取的，因而审慎配置<mirrorOf>*<mirrorOf>，因为如果第一个镜像仓库配置了如此标记，那么如果该仓库即便不存在对应依赖也不会向上游查问。
1.2.7 proxies
用来配置代理。
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd"> ... <proxies> <!--代理元素蕴含配置代理时须要的信息 --> <proxy> <!--代理的惟一定义符，用来辨别不同的代理元素。 --> <id>myproxy</id> <!--该代理是否是激活的那个。true则激活代理。当咱们申明了一组代理，而某个时候只须要激活一个代理的时候，该元素就能够派上用途。 --> <active>true</active> <!--代理的协定。 协定://主机名:端口，分隔成离散的元素以不便配置。 --> <protocol>http</protocol> <!--代理的主机名。协定://主机名:端口，分隔成离散的元素以不便配置。 --> <host>proxy.somewhere.com</host> <!--代理的端口。协定://主机名:端口，分隔成离散的元素以不便配置。 --> <port>8080</port> <!--代理的用户名，用户名和明码示意代理服务器认证的登录名和明码。 --> <username>proxyuser</username> <!--代理的明码，用户名和明码示意代理服务器认证的登录名和明码。 --> <password>somepassword</password> <!--不该被代理的主机名列表。该列表的分隔符由代理服务器指定；例子中应用了竖线分隔符，应用逗号分隔也很常见。 --> <nonProxyHosts>*.google.com|ibiblio.org</nonProxyHosts> </proxy> </proxies> ...</settings>1.2.8 profiles【重要】
依据环境参数来调整构建配置的列表。用于定义一组profile
seetings中的profile是 pom.xml 中 profile 元素的裁剪版本。
它蕴含了id、activation、repositories、pluginRepositories 和 properties 元素。这里的 profile 元素只蕴含这五个子元素是因为这里只关怀构建零碎这个整体（这正是 settings.xml 文件的角色定位），而非独自的我的项目对象模型设置。如果一个 settings.xml 中的 profile 被激活，它的值会笼罩任何其它定义在 pom.xml 中带有雷同 id 的 profile。
（1）repositories
定义了一组近程仓库的列表，当该属性对应的profile被激活时，会应用该近程仓库。
<repositories> <!--蕴含须要连贯到近程仓库的信息 --> <repository> <!--近程仓库惟一标识 --> <id>codehausSnapshots</id> <!--近程仓库名称 --> <name>Codehaus Snapshots</name> <!--如何解决近程仓库里公布版本的下载 --> <releases> <!--true或者false示意该仓库是否为下载某种类型构件（公布版，快照版）开启。 --> <enabled>false</enabled> <!--该元素指定更新产生的频率。Maven会比拟本地POM和近程POM的工夫戳。这里的选项是：always（始终），daily（默认，每日），interval：X（这里X是以分钟为单位的工夫距离），或者never（从不）。 --> <updatePolicy>always</updatePolicy> <!--当Maven验证构件校验文件失败时该怎么做-ignore（疏忽），fail（失败），或者warn（正告）。 --> <checksumPolicy>warn</checksumPolicy> </releases> <!--如何解决近程仓库里快照版本的下载。有了releases和snapshots这两组配置，POM就能够在每个独自的仓库中，为每种类型的构件采取不同的策略。例如，可能有人会决定只为开发目标开启对快照版本下载的反对。参见repositories/repository/releases元素 --> <snapshots> <enabled /> <updatePolicy /> <checksumPolicy /> </snapshots> <!--近程仓库URL，按protocol://hostname/path模式 --> <url>http://snapshots.maven.codehaus.org/maven2</url> <!--用于定位和排序构件的仓库布局类型-能够是default（默认）或者legacy（遗留）。Maven 2为其仓库提供了一个默认的布局；然而，Maven 1.x有一种不同的布局。咱们能够应用该元素指定布局是default（默认）还是legacy（遗留）。 --> <layout>default</layout> </repository></repositories>（2）properties
定义了一组拓展属性，当对应的profile被激活时该属性无效。
<!-- 1. env.X: 在一个变量前加上"env."的前缀，会返回一个shell环境变量。例如,"env.PATH"指代了$path环境变量（在Windows上是%PATH%）。 2. project.x：指代了POM中对应的元素值。例如: <project><version>1.0</version></project>通过${project.version}取得version的值。 3. settings.x: 指代了settings.xml中对应元素的值。例如：<settings><offline>false</offline></settings>通过 ${settings.offline}取得offline的值。 4. java System Properties: 所有可通过java.lang.System.getProperties()拜访的属性都能在POM中应用该模式拜访，例如 ${java.home}。 5. x: 在<properties/>元素中，或者内部文件中设置，以${someVar}的模式应用。 --><properties> <user.install>${user.home}/our-project</user.install></properties>（3）id
全局惟一标识，如果一个 settings.xml 中的 profile 被激活，它的值会笼罩任何其它定义在 pom.xml 中带有雷同 id 的 profile。
（4）pluginRepositories
同repositories差不多，不过该标签定义的是插件的近程仓库。
（5）activation
触发激活该profile的条件。
<activation> <!--profile默认是否激活的标识 --> <activeByDefault>false</activeByDefault> <!--当匹配的jdk被检测到，profile被激活。例如，1.4激活JDK1.4，1.4.0_2，而!1.4激活所有版本不是以1.4结尾的JDK。 --> <jdk>1.5</jdk> <!--当匹配的操作系统属性被检测到，profile被激活。os元素能够定义一些操作系统相干的属性。 --> <os> <!--激活profile的操作系统的名字 --> <name>Windows XP</name> <!--激活profile的操作系统所属家族(如 'windows') --> <family>Windows</family> <!--激活profile的操作系统体系结构 --> <arch>x86</arch> <!--激活profile的操作系统版本 --> <version>5.1.2600</version> </os> <!--如果Maven检测到某一个属性（其值能够在POM中通过${name}援用），其领有对应的name = 值，Profile就会被激活。如果值字段是空的，那么存在属性名称字段就会激活profile，否则按辨别大小写形式匹配属性值字段 --> <property> <!--激活profile的属性的名称 --> <name>mavenVersion</name> <!--激活profile的属性的值 --> <value>2.0.3</value> </property> <!--提供一个文件名，通过检测该文件的存在或不存在来激活profile。missing查看文件是否存在，如果不存在则激活profile。另一方面，exists则会查看文件是否存在，如果存在则激活profile。 --> <file> <!--如果指定的文件存在，则激活profile。 --> <exists>${basedir}/file2.properties</exists> <!--如果指定的文件不存在，则激活profile。 --> <missing>${basedir}/file1.properties</missing> </file></activation>1.2.9 ActiveProfiles
在运行时手工激活的profile。
该元素蕴含了一组 activeProfile 元素，每个 activeProfile 都含有一个 profile id。任何在 activeProfile 中定义的 profile id，不管环境设置如何，其对应的 profile 都会被激活。如果没有匹配的 profile，则什么都不会产生。
<activeProfiles> <!-- 要激活的profile id --> <activeProfile>env-test</activeProfile></activeProfiles>1.2.10 激活profile的三种形式【重要】
下面有提到了两种激活的profile的形式，还有一种能够通过命令行激活profile。
（1）通过ActiveProfiles激活
如题1.2.9 能够同时激活多个profile。
（2）通过activation后果
如题1.2.8 （5）
（3）通过命令行的形式激活
也是咱们常常应用的形式，例如：
mvn -P 咱们能够通过在pom.xml或setting.xml中指定不同环境的profile，在编译构建不同的我的项目时，通过上述的命令行形式激活对应的profIle。例如在开发环境下：
mvn package -P dev 能够打包开环环境下的我的项目。
1.3 Q&A
1.3.1 mirrors与repositories的关系【重要】
从上文能够看到，repository标签与mirror标签都定义了一个近程仓库的地位，那么当一个依赖同时存在于两个仓库时，会先加载那个依赖呢？
这里须要论述一下maven加载真正起作用的repository的步骤，
- 首先获取pom.xml中repository的汇合，而后获取setting.xml中mirror中元素。
- 如果repository的
id和mirror的mirrorOf的值雷同，则该mirror代替该repository。 - 如果该repository找不到对应的mirror，则应用其自身。
- 依此能够失去最终起作用的repository汇合。能够了解mirror是复写了对应id的repository。
mirror相当于一个拦截器，会拦挡被mirrorOf匹配到的repository，匹配准则参照 1.2.6 ，在匹配到后，会用mirror里定义的url替换到repository。
没有配置mirror
配置了mirror
二、Pom.xml详解
上章中setting.xml定义了某个环境下全局我的项目的相干依赖配置，而pom.xml则具体定义了某一个我的项目中的依赖配置。
2.1 pom元素
2.1.1 根本信息
<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> <!-- 公司或者组织的惟一标记，也是打包成jar包门路的根据 --> <!-- 例如com.companyname.project-group，maven打包jar包的门路：/com/companyname/project-group --> <groupId>com.companyname.project-group</groupId> <!-- 我的项目的惟一ID，一个groupId上面可能多个我的项目，就是靠artifactId来辨别的 --> <artifactId>project</artifactId> <!-- 我的项目以后版本，格局为:主版本.次版本.增量版本-限定版本号 --> <version>1.0</version> <!--我的项目产生的构件类型， jar、war次要用来标识我的项目打包出的服务是jar包还是war包 pom个别用作多moudle的我的项目中 顶层的pom用来指定子moudle中须要依赖的版本 详见2.1.3 --> <packaging>jar</packaging> <!--定义了本我的项目的名称与example的网址 --> <name>itoken dependencies</name> <url>www.funtl.com</url></project>根本信息都比拟易懂，次要定义了本我的项目的相干配置阐明，例如惟一坐标、版本、我的项目介绍等。
2.1.2 dependencies【重要】
（1）dependencies
本元素定义了我的项目中所须要的相干依赖信息，也是最重要的元素之一。
<!--该元素形容了我的项目相干的所有依赖。 这些依赖主动从我的项目定义的仓库中下载 --><dependencies> <dependency> <!------------------- 依赖坐标 -------------------> <!--依赖我的项目的坐标三元素：groupId + artifactId + version --> <!--其中三要素的起源就是2.1.1中他人定义好的相干信息 --> <groupId>org.apache.maven</groupId> <artifactId>maven-artifact</artifactId> <version>3.8.1</version> <!------------------- 依赖传递 -------------------> <!--依赖排除，即通知maven只依赖指定的我的项目，不依赖该项目标这些依赖。此元素次要用于解决版本抵触问题 --> <exclusions> <exclusion> <artifactId>spring-core</artifactId> <groupId>org.springframework</groupId> </exclusion> </exclusions> <!-- 可选依赖，用于阻断依赖的传递性。如果在我的项目B中把C依赖申明为可选，那么依赖B的我的项目中无奈应用C依赖 --> <optional>true</optional> <!------------------- 依赖范畴 -------------------> <!--依赖范畴。在我的项目公布过程中，帮忙决定哪些构件被包含进来 - compile：默认范畴，实用于所有阶段，会随着我的项目一起公布; - runtime: 在执行时须要应用，如JDBC驱动，实用运行和测试阶段，不同于例如fastjson，须要在编译时应用; - test: 只在测试时应用，用于编译和运行测试代码，例如junit，不同于junit，在公布时并不需要; - optional: 当我的项目本身被依赖时，标注依赖是否传递。用于间断依赖时应用 --> <scope>test</scope> </dependency></dependencies>（2）如何解决依赖传递问题或jar包版本抵触问题
解决上述问题个别有两种形式：
- 当咱们作为依赖服务提供者时，能够通过
<optional>标签排除掉不想被传递的服务。
<!-- Project A --><project> ... <dependencies> <!-- declare the dependency to be set as optional --> <dependency> <groupId>sample.ProjectB</groupId> <artifactId>Project-B</artifactId> <version>1.0</version> <optional>true</optional> </dependency> </dependencies></project>咱们的A服务中援用了内部的依赖B服务，此时有A -> B，在他人援用咱们时有C -> A ->B，若此时咱们A在提供对外服务时不想让他人依赖B服务，能够在援用B时增加<optional>标签为true，这样带C依赖于A时并不会引入B。如果C在此时想要应用B的相干服务，须要在C的pom中显示的调用B的相干服务。
- 当咱们作为依赖服务使用者时，能够通过
<exclusions>来去除掉咱们依赖包中所不想依赖的其余服务。
如果此时咱们的A服务依赖于B服务，B服务依赖于C服务，则有A ->B ->C，因为某种原因例如jar包抵触，咱们在A中并不想依赖于C服务的版本，能够在调用B服务时去除掉C的相干依赖，而后本人再在A中应用C的相干版本。
<project> ... <dependencies> <dependency> <groupId>sample.ProjectB</groupId> <artifactId>Project-B</artifactId> <version>1.0</version> <exclusions> <exclusion> <!-- 排除掉B中C的相干依赖 --> <groupId>sample.ProjectC</groupId> <artifactId>Project-C</artifactId> </exclusion> </exclusions> </dependency> <!-- 本人援用C的相干版本 --> <dependency> <groupId>sample.ProjectC</groupId> <artifactId>Project-C</artifactId> <version>2.0</version> </dependency> </dependencies></project>2.1.3 <dependencyManagement>
当一个服务中存在有多个moudle时，每个子module都可能援用了雷同的jar包，然而如果将版本保护到子module的pom中，当须要降级时须要批改所有的pom文件版本。maven提供了继承的形式来解决此问题。
<!--在父pom中定义子pom须要的相干依赖 --><dependencyManagement> <dependencies> <dependency> <groupId>org.aspectj</groupId> <artifactId>aspectjweaver</artifactId> <version>1.0.0</version> </dependency> </dependencies></dependencyManagement>在父pom的 <dependencyManagement> 中定义子pom须要的依赖及版本。
<!--在子pom中 如下定义了父pom中相干依赖信息 --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.10.RELEASE</version> <relativePath/> </parent> <dependencies> <dependency> <!--因为援用了父pom 所以能够不指定版本 maven会主动去父pom中查找指定版本 此处为1.0.0 --> <groupId>org.aspectj</groupId> <artifactId>aspectjweaver</artifactId> </dependency> </dependencies>当咱们的pom中有定义父pom的元素后，能够在指定须要的依赖时不指定其版本，maven会帮咱们去父pom中查找相干的版本信息。
2.1.4 properties
properties次要用来定义常量，通过${value}来应用。
<!--配置依赖版本--> <properties> <!-- Environment Settings --> <java.version>1.8</java.version> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding> <!-- Spring cloud Settings --> <spring-cloud.version>Finchley.RELEASE</spring-cloud.version> <spring-boot-admin.version>2.0.1</spring-boot-admin.version> <zipkin.version>2.10.1</zipkin.version> </properties><dependencies> <!--spring cloud--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>${spring-cloud.version}</version> <type>pom</type> <scope>import</scope> </dependency> <!--zipkin--> <dependency> <groupId>io.zipkin.java</groupId> <artifactId>zipkin</artifactId> <version>${zipkin.version}</version> </dependency> <dependencies>此外，maven还通过约定大于配置的形式定义了一些罕用的属性。
| 属性 | 定义 |
|---|---|
| ${basedir} | 寄存pom.xml和所有的子目录 |
| ${basedir}/src/main/java | 我的项目的java源代码 |
| ${basedir}/src/main/resources | 我的项目的资源，比如说property文件，springmvc.xml |
| ${basedir}/src/main/webapp/WEB-INF | web利用文件目录，web我的项目的信息，比方寄存web.xml、本地图片、jsp视图页面 |
| ${basedir}/target | 打包输入目录 |
| ${project.version} | 我的项目版本 |
| ${project.groupId} | 我的项目groupid |
2.1.5 resources
resources标签用来标识我的项目在编译运行时须要额定编译的文件。例如手工引入jar包、不同运行环境对应不同的profile。
<build> <resources> <!--首先将默认resources目录下的所有文件包含 --> <resource> <directory>src/main/resources</directory> <filtering>true</filtering> <!--只编译所有以.fxml结尾的文件 --> <includes> <include>**/*.fxml</include> </includes> <!--排除掉所有的yaml文件 --> <excludes> <exclude>**/*.yaml</exclude> </excludes> </resource> <!--将不同环境下对应的不同yaml或properties文件编译运行 --> <resource> <!-- <directory>src/main/profiles/dev</directory> <directory>src/main/profiles/beta<directory> <directory>src/main/profiles/pre</directory> --> <directory>src/main/profiles/product</directory> <filtering>true</filtering> <includes> <include>**/*.fxml</include> </includes> </resource> <!--将手工引入的jar包编译运行 --> <resource> <directory>lib</directory> <targetPath>BOOT-INF/lib/</targetPath> <includes> <include>**/*.jar</include> </includes> </resource> </resources></build>2.1.6 profile
与setting.xml中profile所不同的是（参照1.2.8），pom中的profile有着更多的标签来形容一组环境。从作用上来辨别的话，个别setting.xml用来标识不同的近程仓库，而pom中的profile个别用来标识以后我的项目属于什么环境，如下是一组常见的pom中的profiles。
<profiles> <profile> <id>dev</id> <!--激活条件 其中默认为该profile 更多激活条件能够参考1.2.8 --> <activation> <activeByDefault>true</activeByDefault> </activation> <!--当此profile被激活时，会将 project.active 的属性赋值为dev --> <properties> <project.active>dev</project.active> </properties> </profile> <profile> <id>test</id> <!--当此profile被激活时，会将 project.active 的属性赋值为test --> <properties> <project.active>test</project.active> </properties> </profile></profiles><resources> <resource> <!--依据不同的环境 project.active 获得不同的值 从而会将不同的环境下的yaml或properties文件编译进我的项目中 达到只须要在编译时指定环境变量即可 不必每次都要批改配置文件 --> <directory>src/main/${project.active}</directory> <filtering>true</filtering> <includes> <include>**/*.fxml</include> </includes> </resource></resources>此外，个别通过 mvn -P dev/beta/pre/product 命令来激活不同的环境，也能够通过其余的形式来激活profile，详见1.2.10。
当然，pom中的profile不止有指定编译环境的性能，同样也能够指定近程仓库等其余性能。
2.1.6 modules
当咱们我的项目中有多个模块时，如果咱们要独自打包的话须要在每一个模块都执行对应的maven命令，然而通过<modules>标签能够将子服务或平级服务进行聚合，只须要打包该服务，也就会将其对应的子模块同时打包。
<modules> <!-- 引入子模块所在的绝对目录 --> <module>springmybatis</module> <!-- 引入同级模块所在的绝对目录 --> <module>../utils</module> </modules>三、null:jrdp-common:null:jar问题解决
3.1包找不到问题
咱们某次在开发性能的时候，在咱们的我的项目中援用了伏羲另外一个零碎的jar包，然而预发环境下编译的时候却发现构建失败，起因是
因为过后我的项目有用到京东本人的仓库，所以咱们过后第一反馈是去仓库中查找，后果发现仓库中是有这个jar包的。
在发现并不是最常见的jar包不存在的问题后，咱们开始剖析报错起因，发现报错的 jrdp-common这个包并不是咱们间接援用的，而是在咱们援用的jar包中援用的，并且 null:jrdp-common:null:jar能够揣测后面应该是 groupID与 version。
假如咱们的我的项目是A我的项目，援用的我的项目是B我的项目，也就是 A->B->jrdp-common
于是咱们关上B我的项目，查看B的pom构造。
发现B我的项目的pom中的确援用了jrdp-common这个包，然而并没有指定版本，是因为继承了 xx-parent这个包，咱们在这个包中的确也找到了指定的版本号，因而就排除了我的项目中没有指定groupid与版本号的问题。
这个时候如同就问题就陷入了思路，然而咱们留神到，咱们之前另一个私服上也是有这个包的，那么之前的在另一个私服上援用如同是没有问题的，咱们查看了私服了上的pom文件，发现也是跟我的项目一样的。
而后咱们就忽然想到，会不会是仓库中的包有问题，果不其然
没有指定parent也没有指定版本号，于是咱们批改了这个版本的pom，至此问题解决。
总结：因为咱们的零碎曾经被好多个团队中转接手过，因而可能在某些中央踩了不少坑，像这种问题应该就是之前的团队上传了一些有问题的jar包，导致依赖不可用，然而因为咱们之前始终用的私服是没有什么问题的，只到这次用到了仓库问题才浮现。
另外，此问题并不具备普适性，然而当遇到了groupid不能未空的时候能够依照此办法进行排查。
作者：京东科技 韩国凯
内容起源：京东云开发者社区