基于IDEA 进行Maven依赖管理

1. 依赖管理概念

Maven 依赖管理是 Maven 软件中最重要的功能之一。Maven 的依赖管理能够帮助开发人员自动解决软件包依赖问题,使得开发人员能够轻松地将其他开发人员开发的模块或第三方框架集成到自己的应用程序或模块中,避免出现版本冲突和依赖缺失等问题。

我们通过定义 POM 文件,Maven 能够自动解析项目的依赖关系,并通过 Maven 仓库自动下载和管理依赖,从而避免了手动下载和管理依赖的繁琐工作和可能引发的版本冲突问题。

总之,Maven 的依赖管理是 Maven 软件的一个核心功能之一,使得软件包依赖的管理和使用更加智能和方便,简化了开发过程中的工作,并提高了软件质量和可维护性。

2. Maven工程核心信息配置和解读(GAVP)

位置:pom.xml


<modelVersion>4.0.0modelVersion>

<groupId>com.companyname.project-groupgroupId>

<artifactId>projectartifactId>

<version>1.0.0version>


<packaging>jar/pom/warpackaging>

3. Maven工程依赖管理配置

位置:pom.xml

依赖管理和依赖添加


<dependencies>
    
    <dependency>
        <groupId>log4jgroupId>
        <artifactId>log4jartifactId>
        <version>1.2.17version>
        
        <scope>runtimescope>
    dependency>

dependencies>

依赖版本统一提取和维护


<properties>
  
  <junit.version>4.12junit.version>
  
  <project.build.sourceEncoding>UTF-8project.build.sourceEncoding>
  <project.reporting.outputEncoding>UTF-8project.reporting.outputEncoding>
properties>

<dependencies>
  <dependency>
    <groupId>junitgroupId>
    <artifactId>junitartifactId>
    
    <version>${junit.version}version>
  dependency>
dependencies>

4. 依赖范围

通过设置坐标的依赖范围(scope),可以设置 对应jar包的作用范围:编译环境、测试环境、运行环境

依赖范围 描述
compile 编译依赖范围,scope 元素的缺省值。使用此依赖范围的 Maven 依赖,对于三种 classpath 均有效,即该 Maven 依赖在上述三种 classpath 均会被引入。例如,log4j 在编译、测试、运行过程都是必须的。
test 测试依赖范围。使用此依赖范围的 Maven 依赖,只对测试 classpath 有效。例如,Junit 依赖只有在测试阶段才需要。
provided 已提供依赖范围。使用此依赖范围的 Maven 依赖,只对编译 classpath 和测试 classpath 有效。例如,servlet-api 依赖对于编译、测试阶段而言是需要的,但是运行阶段,由于外部容器已经提供,故不需要 Maven 重复引入该依赖。
runtime 运行时依赖范围。使用此依赖范围的 Maven 依赖,只对测试 classpath、运行 classpath 有效。例如,JDBC 驱动实现依赖,其在编译时只需 JDK 提供的 JDBC 接口即可,只有测试、运行阶段才需要实现了 JDBC 接口的驱动。
system 系统依赖范围,其效果与 provided 的依赖范围一致。其用于添加非 Maven 仓库的本地依赖,通过依赖元素 dependency 中的 systemPath 元素指定本地依赖的路径。鉴于使用其会导致项目的可移植性降低,一般不推荐使用。
import 导入依赖范围,该依赖范围只能与 dependencyManagement 元素配合使用,其功能是将目标 pom.xml 文件中 dependencyManagement 的配置导入合并到当前 pom.xml 的 dependencyManagement 中。

5. Maven工程依赖下载失败错误解决(重点)

在使用 Maven 构建项目时,可能会发生依赖项下载错误的情况,主要原因有以下几种:

  1. 下载依赖时出现网络故障或仓库服务器宕机等原因,导致无法连接至 Maven 仓库,从而无法下载依赖。
  2. 依赖项的版本号或配置文件中的版本号错误,或者依赖项没有正确定义,导致 Maven 下载的依赖项与实际需要的不一致,从而引发错误。
  3. 本地 Maven 仓库或缓存被污染或损坏,导致 Maven 无法正确地使用现有的依赖项。

解决方案:

  1. 检查网络连接和 Maven 仓库服务器状态。

  2. 确保依赖项的版本号与项目对应的版本号匹配,并检查 POM 文件中的依赖项是否正确。

  3. 清除本地 Maven 仓库缓存(lastUpdated 文件),因为只要存在lastupdated缓存文件,刷新也不会重新下载。本地仓库中,根据依赖的gav属性依次向下查找文件夹,最终删除内部的文件,刷新重新下载即可!

    例如: pom.xml依赖

    <dependency>
      <groupId>com.alibabagroupId>
      <artifactId>druidartifactId>
      <version>1.2.8version>
    dependency>
    

    文件:
    基于IDEA 进行Maven依赖管理_第1张图片

  4. 或者可以将清除lastUpdated文件的操作写在一个脚本文件中,手动创建文件"clearLastUpdated.bat",名字任意,但是后缀必须是bat,将以下内容复制到文件中

主要修改 3 4 行

cls 
@ECHO OFF 
SET CLEAR_PATH=D: 
SET CLEAR_DIR=D:\maven-repository(本地仓库路径)
color 0a 
TITLE ClearLastUpdated For Windows 
GOTO MENU 
:MENU 
CLS
ECHO. 
ECHO. * * * *  ClearLastUpdated For Windows  * * * * 
ECHO. * * 
ECHO. * 1 清理*.lastUpdated * 
ECHO. * * 
ECHO. * 2 查看*.lastUpdated * 
ECHO. * * 
ECHO. * 3 退 出 * 
ECHO. * * 
ECHO. * * * * * * * * * * * * * * * * * * * * * * * * 
ECHO. 
ECHO.请输入选择项目的序号: 
set /p ID= 
IF "%id%"=="1" GOTO cmd1 
IF "%id%"=="2" GOTO cmd2 
IF "%id%"=="3" EXIT 
PAUSE 
:cmd1 
ECHO. 开始清理
%CLEAR_PATH%
cd %CLEAR_DIR%
for /r %%i in (*.lastUpdated) do del %%i
ECHO.OK 
PAUSE 
GOTO MENU 
:cmd2 
ECHO. 查看*.lastUpdated文件
%CLEAR_PATH%
cd %CLEAR_DIR%
for /r %%i in (*.lastUpdated) do echo %%i
ECHO.OK 
PAUSE 
GOTO MENU 

基于IDEA 进行Maven依赖管理_第2张图片

6. Maven工程Build构建配置

项目构建是指将源代码、依赖库和资源文件等转换成可执行或可部署的应用程序的过程,在这个过程中包括编译源代码、链接依赖库、打包和部署等多个步骤。

默认情况下,构建不需要额外配置,都有对应的缺省配置。当然了,我们也可以在pom.xml定制一些配置,来修改默认构建的行为和产物!

例如:

  1. 指定构建打包文件的名称,非默认名称
  2. 制定构建打包时,指定包含文件格式和排除文件
  3. 打包插件版本过低,配置更高版本插件

构建配置是在pom.xml / build标签中指定!

指定打包命名


<build>
  <finalName>定义打包名称finalName>
build>  

基于IDEA 进行Maven依赖管理_第3张图片

指定打包文件

在配置文件 resources 中创建一个 test.xml
基于IDEA 进行Maven依赖管理_第4张图片

创建一些内容
基于IDEA 进行Maven依赖管理_第5张图片

进行打包,可以看到 test.xml 也进行了打包,因为 java 下面写的类,下面 resources 配置文件,也会打包
基于IDEA 进行Maven依赖管理_第6张图片

但是如果将 test.xml 文件放入到 java 下,而不是 resources 下(java 下面只允许存在 java 类,resources 文件下只允许存在 配置文件)

基于IDEA 进行Maven依赖管理_第7张图片

基于IDEA 进行Maven依赖管理_第8张图片
打包后,可以看到,还是只有 User 类,并没有 student.xml 文件被打包
基于IDEA 进行Maven依赖管理_第9张图片

如果在java文件夹中添加java类,会自动打包编译到classes文件夹下!

但是在java文件夹中添加xml文件,默认不会被打包!

默认情况下,按照maven工程结构放置的文件会默认被编译和打包!

除此之外、我们可以使用resources标签,指定要打包资源的文件夹要把哪些静态资源打包到 classes根目录下!

应用场景:mybatis中有时会将用于编写SQL语句的映射文件和mapper接口都写在src/main/java下的某个包中,此时映射文件就不会被打包,如何解决

<build>
    
    <resources>
        <resource>
            
            <directory>src/main/javadirectory>
            <includes>
                
                <include>**/*.xmlinclude>
            includes>
        resource>
    resources>
build>

基于IDEA 进行Maven依赖管理_第10张图片

配置依赖插件

dependencies标签下引入开发需要的jar包!我们可以在build/plugins/plugin标签引入插件!

常用的插件:修改jdk版本、tomcat插件、mybatis分页插件、mybatis逆向工程插件等等!

<build>
  <plugins>
      
      <plugin>
        <groupId>org.apache.maven.pluginsgroupId>
        <artifactId>maven-compiler-pluginartifactId>
        <configuration>
          <source>1.8source>
          <target>1.8target>
          <encoding>UTF-8encoding>
        configuration>
      plugin>
      
      <plugin>
        <groupId>org.apache.tomcat.mavengroupId>
        <artifactId>tomcat7-maven-pluginartifactId>
         <version>2.2version>
          <configuration>
          <port>8090port>
          <path>/path>
          <uriEncoding>UTF-8uriEncoding>
          <server>tomcat7server>
        configuration>
      plugin>
    plugins>
build>

Tomecat 添加到 maven 插件中教程,无须在单独配置 Tomcat 了

你可能感兴趣的:(JAVA进阶之路,intellij-idea,maven,java)