使用Maven那么久了,你对企业级Maven的核心配置了解多少?

简介: 相信从事Java工作的小伙伴们多多少少都会接触到Maven。使用Maven来搭建项目,能够极大的方便我们构建项目的依赖关系,对于项目中需要依赖的Jar包,也只是简单的在pom.xml中进行配置即可。可以说,Maven能够极大的提高我们的开发效率和项目的维护效率,能够统一项目的依赖环境,提高团队的协作效率。然而,尽管使用Maven的小伙伴很多,但真正掌握了Maven核心配置的又有多少呢?

项目依赖

项目依赖是指Maven 通过依赖传播、依赖优先原则、可选依赖、排除依赖、依赖范围等特性来管理项目classpath。

依赖传播特性

我们的项目通常需要依赖第三方组件,而第三方组件又会依赖其它组件遇到这种情况Maven会将依赖网络中的所有节点都会加入classpath当中,这就是Maven的依赖传播特性。

例如下面的配置

<!-- 添加spring mvc依赖-->
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-webmvc</artifactId>
  <version>5.2.9.RELEASE</version>
</dependency>

项目直接依赖了spring-webmvc 叫直接依赖,而对commons-logging 依赖是通过webmvc传递的所以叫间接依赖。

依赖优先原则

基于依赖传播特性,导致整个依赖网络会很复杂,难免会出现相同组件不同版本的情况。Maven此时会基于依赖优先原则选择其中一个版本。

  • 第一原则:最短路径优先。
  • 第二原则:相同路径下配置在前的优先。

第一原则示例

<!-- 直接添加commons-logging -->
<dependency>
  <groupId>commons-logging</groupId>
  <artifactId>commons-logging</artifactId>
  <version>1.2</version>
</dependency>

上述例子中commons-logging 通过spring-webmvc 依赖了1.1.3,而项目中直接依赖了1.2,基于最短路径原则项目最终引入的是1.2 版本。

第二原则示例

主要步骤如下所示:

(1)添加一个新工程Project B

(2) 配置Project B 依赖 spring-web.3.2.9-RELEASE

(3)当前工程直接依赖 Project B

配置完之后,当前工程 project A 有两条路径可以依赖 spring-web,选择哪一条 就取决于 对 webmvc 和 Project B的配置先后顺序。

  • Project A==> spring-webmvc 5.2.9-RELEASE ==> spring-web 5.2.9-RELEASE
  • Project A==>  Project B 1.0.SNAPSHOT ==>spring-web.3.2.9-RELEASE

注意:在同一pom文件,第二原则不再适用。如下配置,最终引用的是1.2 版本,而不是配置在前面的1.1.1版本。

<!-- 在1.2 之前添加 commons-logging -->
<dependency>
 <groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.1.1</version>
</dependency>
<dependency>
 <groupId>commons-logging</groupId>
 <artifactId>commons-logging</artifactId>
 <version>1.2</version>
</dependency>

可选依赖

可选依赖表示这个依赖不是必须的。通过在<dependency></dependency>中添 加<optional>true</optional> 表示,默认是不可选的。可选依赖不会被传递。

排除依赖

即排除指定的间接依赖。通过配置<exclusions></exclusions>配置排除指定组件。

例如,我们可以使用下面的配置来排除对于spring-web的依赖。

<!-- 排除指定项目 -->
<exclusions>
  <exclusion>
   <groupId>org.springframework</groupId>
   <artifactId>spring-web</artifactId>
  </exclusion>
</exclusions>

依赖范围

像junit 这个组件 我们只有在运行测试用例的时候去要用到,这就没有必要在打包的时候把junit.jar 包过构建进去,可以通过Maven 的依赖范围配置<scope></scope>来达到这种目的。Maven 总共支持以下四种依赖范围:

  • compile(默认): 编译范围,编译和打包都会依赖。
  • provided: 提供范围,编译时依赖,但不会打包进去。如:servlet-api.jar
  • runtime: 运行时范围,打包时依赖,编译不会。如:mysql-connector-java.jar
  • test: 测试范围,编译运行测试用例依赖,不会打包进去。如:junit.jar
  • system: 表示由系统中classpath指定。编译时依赖,不会打包进去。配合<systemPath></systemPath> 一起使用。示例:java.home下的tool.jar

system 除了可以用于引入系统classpath 中包,也可以用于引入系统非maven 收录的第三方Jar,做法是将第三方Jar放置在 项目的 lib 目录下,然后配置 相对路径,但因system 不会打包进去所以需要配合 maven-dependency-plugin 插件配合使用。当然,我还是推荐小伙伴们通过 将第三方Jar手动install 到仓库。

接下来,我们就列举几个简单的使用示例。

  • system 的通常使用方式
<dependency>
     <groupId>com.sun</groupId>
     <artifactId>tools</artifactId>
     <version>${java.version}</version>
     <scope>system</scope>
     <optional>true</optional>
     <systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
  • system 另外使用方式 ,将工程内的jar直接引入
<dependency>
  <groupId>jsr</groupId>
  <artifactId>jsr</artifactId>
  <version>3.5</version>
  <scope>system</scope>
  <optional>true</optional>
  <systemPath>${basedir}/lib/jsr305.jar</systemPath>
</dependency>
  • 通过插件 将system 的jar 打包进去
<plugin>
  <groupId>org.apache.maven.plugins</groupId>\
  <artifactId>maven-dependency-plugin</artifactId>
  <version>2.10</version>
  <executions>
    <execution>
      <id>copy-dependencies</id>
      <phase>compile</phase>
      <goals>
        <goal>copy-dependencies</goal>
      </goals>
      <configuration>
<outputDirectory>${project.build.directory}/${project.build.finalName}/WEB-INF/lib</outputDirectory>
        <includeScope>system</includeScope>
        <excludeGroupIds>com.sun</excludeGroupIds>
      </configuration>
    </execution>
  </executions>
</plugin>
  • 手动加入本地仓库
mvn install:install-file -Dfile=mykit-transaction-message.jar -DgroupId=io.mykit -DartifactId=mykit-transaction-message -Dversion=1.0.0-RELEASE -Dpackaging=jar

项目聚合与继承

聚合

聚合是指将多个模块整合在一起,统一构建,避免一个一个的构建。聚合需要个父工程,然后使用 <modules></modules> 进行配置其中对应的是子工程的相对路径。例如下面的配置。

<modules>
  <module>mykit-dao</module>
  <module>mykit-service</module>
</modules>

继承

继承是指子工程直接继承父工程 当中的属性、依赖、插件等配置,避免重复配置。继承包括如下几种方式。

  • 属性继承
  • 依赖继承
  • 插件继承

注意:上面的三个配置子工程都可以进行重写,重写之后以子工程的为准。

依赖管理

通过继承的特性,子工程是可以间接依赖父工程的依赖,但多个子工程依赖有时并不一至,这时就可以在父工程中加入<dependencyManagement></dependencyManagement> 声明该工程需要的JAR包,然后在子工程中引入。例如下面的配置。

<!-- 父工程中声明 junit 4.12 -->
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
    </dependency>
  </dependencies>
</dependencyManagement>
<!-- 子工程中引入 -->
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
</dependency>

项目属性

通过 <properties></properties> 配置属性参数,可以简化配置。例如下面的配置。

<!-- 配置proName属性 -->
<properties>
  <projectName>projectName</projectName>
</properties>

我们可以在pom.xml文件中使用下面的形式来引入配置的参数。

${projectName}

接下来,我们再来看几个Maven的默认属性,如下所示。

  • ${basedir} 项目根目录
  • ${version}表示项目版本;
  • ${project.basedir}同${basedir};
  • ${project.version}表示项目版本,与${version}相同;
  • ${project.build.directory} 构建目录,缺省为target
  • ${project.build.sourceEncoding}表示主源码的编码格式;
  • ${project.build.sourceDirectory}表示主源码路径;
  • ${project.build.finalName}表示输出文件名称;
  • ${project.build.outputDirectory} 构建过程输出目录,缺省为target/classes

项目构建配置

构建资源配置

基本配置示例:

<defaultGoal>package</defaultGoal>
<directory>${basedir}/target2</directory>
<finalName>${artifactId}-${version}</finalName>

说明:

  • defaultGoal:执行构建时默认的goal或phase,如jar:jar或者package等
  • directory:构建的结果所在的路径,默认为${basedir}/target目录
  • finalName:构建的最终结果的名字,该名字可能在其他plugin中被改变

resources 配置示例

<resources>
  <resource>
   <directory>src/main/java</directory>
   <includes>
     <include>**/*.MF</include>
     <include>**/*.xml</include>
   </includes>
   <filtering>true</filtering>
  </resource>
  <resource>
   <directory>src/main/resources</directory>
   <includes>
     <include>**/*</include>
     <include>*</include>
   </includes>
   <filtering>true</filtering>
  </resource>
 </resources>

说明:

  • resources:build过程中涉及的资源文件
  • targetPath:资源文件的目标路径
  • directory:资源文件的路径,默认位于${basedir}/src/main/resources/目录下
  • includes:一组文件名的匹配模式,被匹配的资源文件将被构建过程处理
  • excludes:一组文件名的匹配模式,被匹配的资源文件将被构建过程忽略。同时被includes和excludes匹配的资源文件,将被忽略。
  • filtering:默认false ,true 表示 通过参数 对 资源文件中 的${key} 在编译时进行动态变更。替换源 -Dkey 和pom 中的值 或中指定的properties 文件。
相关文章
|
3月前
|
Java Maven
2022最新版超详细的Maven下载配置教程、IDEA中集成maven(包含图解过程)、以及导入项目时jar包下载不成功的问题解决
这篇文章是一份关于Maven的安装和配置指南,包括下载、环境变量设置、配置文件修改、IDEA集成Maven以及解决jar包下载问题的方法。
2022最新版超详细的Maven下载配置教程、IDEA中集成maven(包含图解过程)、以及导入项目时jar包下载不成功的问题解决
|
3月前
|
Java Maven
解决idea每次新建maven项目都需要重新配置maven的问题
解决idea每次新建maven项目都需要重新配置maven的问题
145 1
|
4月前
|
Java Maven 编译器
Java编译器注解运行和自动生成代码问题之@AutoService工作问题如何解决
Java编译器注解运行和自动生成代码问题之@AutoService工作问题如何解决
191 1
|
26天前
|
Java Shell 应用服务中间件
Mac系统下配置环境变量:Javajdk、maven、tomcat 环境变量配置及对应配置文件
这篇文章介绍了如何在Mac系统下配置Java JDK、Maven和Tomcat的环境变量,包括配置文件的选择、解决环境变量在zsh shell中无效的问题、查看和设置系统环境变量的方法,以及JDK和Maven的下载、配置和测试步骤。
1058 1
Mac系统下配置环境变量:Javajdk、maven、tomcat 环境变量配置及对应配置文件
|
25天前
|
Java jenkins 持续交付
Centos7下docker的jenkins下载并配置jdk与maven
通过上述步骤,您将成功在CentOS 7上的Docker容器中部署了Jenkins,并配置好了JDK与Maven,为持续集成和自动化构建打下了坚实基础。
77 1
|
1月前
|
Java Shell Maven
Flink-11 Flink Java 3分钟上手 打包Flink 提交任务至服务器执行 JobSubmit Maven打包Ja配置 maven-shade-plugin
Flink-11 Flink Java 3分钟上手 打包Flink 提交任务至服务器执行 JobSubmit Maven打包Ja配置 maven-shade-plugin
93 4
|
1月前
|
Java Maven
震惊!idea专业版如何配置maven国内源手把手教学
文章提供了如何在IDEA专业版中配置Maven使用国内源(如阿里云)的详细步骤,以加快依赖下载速度,并解释了配置国内源的原因。
382 0
震惊!idea专业版如何配置maven国内源手把手教学
|
2月前
|
XML Java Maven
idea配置maven步骤及常见问题
本文介绍了在IDEA中配置Maven的详细步骤,包括Maven的下载、系统环境变量的配置、Maven本地仓库的设置、镜像加速的配置,以及在IDEA中指定Maven路径和配置文件。同时,还提供了解决每次新建项目需要重新手动配置Maven问题的方法。
idea配置maven步骤及常见问题
|
3月前
|
安全 Java Maven
优化Maven镜像配置:使用阿里云加速依赖下载
更新Maven镜像配置至关重要,尤其使用阿里云仓库时。在`settings.xml`中加入特定镜像配置可显著提升依赖下载速度。示例配置指定了阿里云镜像ID、替代表态仓库、安全的URL、默认布局及启用版本管理。需定位至用户目录下的`.m2/`文件夹编辑`settings.xml`,添加镜像信息后保存测试。若下载仍慢,考虑网络状况或备选镜像。多镜像设置时需注意避免冲突。
509 3
|
4月前
|
Java Maven 开发者
入职必会-开发环境搭建14-IDEA配置Maven
在 IDEA 中配置 Maven 可以帮助开发者更方便地管理项目依赖、构建项目和部署应用程序。要在 IDEA 中配置 Maven,可以按照以下步骤进行。
入职必会-开发环境搭建14-IDEA配置Maven

推荐镜像

更多
下一篇
无影云桌面