详解IDEA多module项目maven依赖的一些说明

 更新时间:2018年10月26日 10:41:29   作者:sandman  
这篇文章主要介绍了详解IDEA多module项目maven依赖的一些说明,小编觉得挺不错的,现在分享给大家,也给大家做个参考。一起跟随小编过来看看吧

不管eclipse有没有被被时代抛弃,反正是被我抛弃了,因为IDEA是真的好用

现在公司的项目基本都是基于maven的多module项目,controller,service,model,dao等都被分成了不同的module,这样做当然也是为了解耦。

这些module可根据需要在pom.xml配置来打成war包或者jar包

<packaging>jar</packaging>

web主项目设置packaging级别为war,dao、model这些module设置packaging级别为jar。

module之间可以通过module自己的pom.xml来进行相互引用或依赖,如:

<dependency>
      <groupId>cn.com.autohome.mall</groupId>
      <artifactId>mall-common</artifactId>
    </dependency>
    <dependency>
      <groupId>cn.com.autohome.mall</groupId>
      <artifactId>mall-api-model</artifactId>
    </dependency>

这样在 File -> project structure 下,选中主web项目

从上面的截图可以看出来依赖的第三方jar和依赖项目子module的区别。

maven在执行install,packaging是jar的会被打成jar放在target目录下,packaging是war的会被打成war放在target目录下。
另外两个target目录会有一点区别,war的target目录会多出来一个和module同名的文件夹,这个文件夹和war解压后完全一致。

所有依赖的jar(包括依赖的module,被打成jar)都会被放lib下
这样在部署的时候,只需要部署相应的war即可。

关于Maven pom.xml中的元素modules、parent、properties以及import

多个module不需要分别执行mvn命令,可以使用聚合(aggregator)来一次构建全部模块

modules

在父pom.xml中通过

 <modules>
    <!-- 模块都写在此处 -->
   <module>mall-common</module>
   <module>mall-api-model</module>
 </modules>

来引用所有需要构建的子模块

parent

继承,和java中的继承相当,作用就是复用

场景

若每个子模块都都用的了spring,那么我们是不是每个子模块都需要单独配置spring依赖了?这么做是可以的,但是我们有更优的做法,那就是继承,用parent来实现。

实现

父(account-aggregator)pom.xml

 <modules>
   <!-- 模块都写在此处 -->
  <module>mall-common</module>
  <module>mall-api-model</module>
 </modules>
 
 <dependencies> <!-- 配置共有依赖 -->
  <!-- spring 依赖 -->
   <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.0.2.RELEASE</version>
  </dependency>
   ······
  <!-- junit 依赖 -->
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.7</version>
   <scope>test</scope>
  </dependency>
 </dependencies>

子pom.xml

<parent>
  <groupId>xx.xx.xx</groupId>
  <artifactId>aggregator</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <relativePath>../pom.xml</relativePath> <!-- 与不配置一样,默认就是寻找上级目录下得pom.xml -->
</parent>

 <dependencies>  <!-- 配置自己独有依赖 -->
  <dependency>
   <groupId>javax.mail</groupId>
   <artifactId>mail</artifactId>
   <version>1.4.3</version>
  </dependency>
  <dependency>
   <groupId>com.icegreen</groupId>
   <artifactId>greenmail</artifactId>
   <version>1.4.1</version>
   <scope>test</scope>
  </dependency>
 </dependencies>

依赖管理

继承可以消除重复,那是不是就没有问题了? 答案是存在问题,假设将来需要添加一个新的子模块util,只是提供一些简单的帮助工具,不需要依赖spring、junit,那么继承后就依赖上了,有没有什么办法了?
有,maven已经替我们想到了,那就是dependencyManagement元素,既能让子模块继承到父模块的依赖配置,又能保证子模块依赖使用的灵活性。在dependencyManagement元素下得依赖声明不会引入实际的依赖,不过它能够约束dependencies下的依赖使用。

在父pom.xml中配置dependencyManagement元素

<modules>
   <!-- 模块都写在此处 -->
  <module>mall-common</module>
  <module>mall-api-model</module>
 </modules>
 
 <dependencyManagement>
   <dependencies> <!-- 配置共有依赖 -->
   <!-- spring 依赖 -->
   <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>4.0.2.RELEASE</version>
  </dependency>
  ······
 </dependencies>
 </dependencyManagement>

子pom.xml

<dependencies>
  <!-- spring 依赖 -->
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
  </dependency>
   <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-beans</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-context-support</artifactId>
  </dependency>
  
   <!-- junit 依赖 -->
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
  </dependency>
  <dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>4.0.2.RELEASE</version>
  </dependency>
  <dependency>
    <groupId>com.alibaba</groupId>
    <artifactId>druid</artifactId>
    <version>1.0.16</version>
  </dependency>
 </dependencies>

使用这种依赖管理机制似乎不能减少太多的POM配置,就少了version(junit还少了个scope),感觉没啥作用呀;其实作用还是挺大的,父POM使用dependencyManagement能够统一项目范围中依赖的版本,当依赖版本在父POM中声明后,子模块在使用依赖的时候就无须声明版本,也就不会发生多个子模块使用版本不一致的情况,帮助降低依赖冲突的几率。如果子模块不声明依赖的使用,即使该依赖在父POM中的dependencyManagement中声明了,也不会产生任何效果。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

相关文章

  • Spring开发中自定义注解的使用详解

    Spring开发中自定义注解的使用详解

    这篇文章主要介绍了Spring开发中自定义注解的使用详解,在Java项目中,可以自定义注解,方便进行某些处理操作,提供开发效率,需要的朋友可以参考下
    2024-01-01
  • springboot 实现mqtt物联网的示例代码

    springboot 实现mqtt物联网的示例代码

    这篇文章主要介绍了springboot 实现mqtt物联网,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2021-03-03
  • Spring中的三级缓存与循环依赖详解

    Spring中的三级缓存与循环依赖详解

    Spring三级缓存是Spring框架中用于解决循环依赖问题的一种机制,这篇文章主要介绍了Spring三级缓存与循环依赖的相关知识,本文给大家介绍的非常详细,需要的朋友可以参考下
    2024-05-05
  • Java Mybatis框架由浅入深全解析中篇

    Java Mybatis框架由浅入深全解析中篇

    MyBatis是一个优秀的持久层框架,它对jdbc的操作数据库的过程进行封装,使开发者只需要关注SQL本身,而不需要花费精力去处理例如注册驱动、创建connection、创建statement、手动设置参数、结果集检索等jdbc繁杂的过程代码本文将为大家深入的介绍一下MyBatis的使用
    2022-07-07
  • 详解SpringBoot封装使用JDBC

    详解SpringBoot封装使用JDBC

    这篇文章主要介绍了SpringBoot封装JDBC使用教程,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友可以参考下
    2021-12-12
  • IDEA配置Tomcat后,控制台tomcat catalina log出现乱码问题

    IDEA配置Tomcat后,控制台tomcat catalina log出现乱码问题

    本文介绍了如何通过设置Tomcat和IDEA的编码格式来解决编码问题,首先尝试修改Tomcat的logging.properties文件中的编码设置,如果未解决问题,则调整IDEA的编码设置,通过修改vmoptions文件来全局设置IDEA的编码格式,作者分享了个人成功解决问题的方法和步骤,供其他开发者参考
    2024-09-09
  • Java命令行运行错误之找不到或无法加载主类问题的解决方法

    Java命令行运行错误之找不到或无法加载主类问题的解决方法

    这篇文章主要给大家介绍了关于Java命令行运行错误之找不到或无法加载主类问题的解决方法,文中通过实例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
    2022-01-01
  • 详解SpringCloudGateway内存泄漏问题

    详解SpringCloudGateway内存泄漏问题

    这篇文章主要介绍了详解SpringCloudGateway内存泄漏问题,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2020-07-07
  • 详解Java分布式系统中session一致性问题

    详解Java分布式系统中session一致性问题

    这篇文章主要介绍了Java分布式系统中session一致性问题,对分布式系统感兴趣的同学,要仔细看一下
    2021-04-04
  • Spring boot + mybatis + Vue.js + ElementUI 实现数据的增删改查实例代码(二)

    Spring boot + mybatis + Vue.js 

    这篇文章主要介绍了Spring boot + mybatis + Vue.js + ElementUI 实现数据的增删改查实例代码(二),非常不错,具有参考借鉴价值,需要的朋友可以参考下
    2017-05-05

最新评论