ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

Maven安装与配置全攻略:从核心概念到settings.xml避坑指南

Maven安装与配置全攻略:从核心概念到settings.xml避坑指南 接触Maven这些年我帮人排查过最多的一个问题不是依赖冲突也不是构建失败而是“配置了等于没配置”。最典型的就是新同事往pom.xml里加了个依赖IDEA右下角转了半天圈最后报错Could not transfer artifact。你问他settings.xml放在哪、IDEA里User settings file那一栏填的是什么答不上来。一篇合格的Maven教程不应该只教你怎么下压缩包、配环境变量还得把配置背后那些不起眼却决定成败的细节讲清楚。这篇文章打算把Maven安装和配置这条路上的坑一次说透从核心概念、版本选型、环境变量到settings.xml三座大山、IDEA集成、高频翻车现场再到Nexus私服和上传中央仓库。内容偏实操每一步都有可复现的命令、配置和截图级描述适合刚入门的Java新手也适合被各种诡异报错折磨的进阶用户。1. 搞定Maven之前先花五分钟搞懂三个核心概念你在网上搜“Maven是干嘛的”会看到一堆抽象解释项目构建工具、依赖管理工具、项目信息管理工具。对新手来说这些词句就像“空气是透明的一样”正确但没用。我习惯用更直白的方式讲。1.1 没有Maven的年代Java项目是怎么被玩坏的想象一个传统Java Web项目。你想用Log4j打日志得先打开浏览器找到下载页把log4j的jar包下下来拖进项目的lib目录右键Add to Build Path。你以为完了还没。Log4j自己还依赖别的jar你得照着文档把那一串jar全部手动下载全部拖进lib全部加到Build Path。这还只是第一个依赖。等你引入一个Spring框架依赖树可能有几十上百个jar手动管理立刻崩盘。更可怕的是版本冲突项目A模块需要log4j 1.2.17B模块需要log4j 2.x两个jar都躺在lib里ClassLoader加载顺序一变线上就冒出一堆“找不到方法”“类转换异常”。多人协作时这个问题会被无限放大。新人拉下代码后lib目录和你不一致编译不过你在本地调得好好的一打包到测试环境就另一个行为。用一句话总结没有构建工具之前Java项目的依赖管理本质上是靠人的记忆和自觉迟早要出事。1.2 坐标、仓库、生命周期Maven的骨架Maven解决这个问题的思路可以拆成三个概念。坐标。Maven给每个jar包分配了一个三维地址长这样dependency groupIdcn.hutool/groupId artifactIdhutool-all/artifactId version5.8.27/version /dependencygroupId通常是组织域名的反写artifactId是项目/模块名version就是版本号。这个三元组在全球范围内唯一确定一个jar包就像快递收货地址一样精确。你在pom.xml里写下这段Maven就知道你要哪个jar。仓库。Maven把jar包从“手动下载”变成“自动拉取”靠的就是仓库。它有两层结构本地仓库和远程仓库。本地仓库是你电脑上的一个目录默认是~/.m2/repository所有下载过的jar都被缓存到这里。远程仓库里最核心的是中央仓库Central Repository地址是https://repo.maven.apache.org/maven2/全球开发者把自己项目的jar包发布到这个服务器。Maven的工作流程是优先查本地仓库没有就从远程仓库下载并缓存。生命周期。Maven把构建过程拆成一串固定阶段比如clean清理target目录compile编译源码test跑单元测试package打成jar或war包install把产物安装到本地仓库deploy把产物发布到远程仓库你执行mvn install时它会老老实实从编译开始跑完一整套流程。这个标准化流程极大降低了团队协作的沟通成本。1.3 为什么不直接选Gradle很多新手会在Maven和Gradle之间纠结。我直接给结论新人先学Maven。对比项MavenGradle构建脚本XML严谨但啰嗦Groovy/Kotlin DSL灵活增量构建一般强构建更快学习曲线平缓陡峭生态默认绝大多数Java老项目都在用安卓、新项目更常见可读性结构统一换项目无障碍自由度大维护成本可能更高不是说Gradle不好Gradle的构建性能确实优于Maven但它的灵活是一把双刃剑新手很容易把构建脚本写得花里胡哨。Maven的好处是“规矩”项目结构、构建流程、配置写法都高度标准化你换一个公司、看一个新项目基本能零成本上手。等把Maven玩明白了再学Gradle时你会发现两者理念是相通的。2. 下载安装与JDK版本匹配第一道门槛比想象中容易出错Maven安装本身不难但“版本匹配”这件事劝退了不少人。我见过有人装了Maven 3.2配JDK 17怎么都跑不起来最后发现是版本太老压根不认识新版JDK的class文件格式。2.1 Maven版本与JDK版本的兼容关系选Maven版本之前先看一眼自己的JDK版本。执行java -version我列一个常用的兼容对照表都是实测过的组合Maven版本最低JDK要求使用建议Maven 3.6.3JDK 1.7老项目常见维护期尽量替换Maven 3.8.xJDK 1.8从3.8.6起实际要求JDK 8当前覆盖面最广Maven 3.9.xJDK 8现阶段推荐首选Maven 4.xJDK 8迭代快不建议生产环境如果你用的是JDK 17或JDK 21这种新版本LTS放心用Maven 3.9.x完全没问题。如果你公司的老项目还在JDK 8甚至JDK 7上那Maven 3.6.3反而是最稳妥的选择因为它对老JDK的兼容性最好。核心原则就一条Maven版本别比你项目用的JDK老太多。顺便吐槽一个我总在搜索记录里看到的东西“maven 3.88版本下载”。官方从来没有3.88这个版本这大概率是某些下载站自己编的版本号看到这种网站反而要小心尽量别从这类页面下载安装包。2.2 官网下载入口和安装包命名Maven官网下载页是https://maven.apache.org/download.cgi。打开后你会看到一堆文件和目录apache-maven-3.9.x-bin.zipWindows下用的二进制包apache-maven-3.9.x-bin.tar.gzmacOS和Linux下用的二进制包apache-maven-3.9.x-src.zip和apache-maven-3.9.x-src.tar.gz源码包注意带src的是源码包下下来也不能直接跑别下错。国内访问官网速度有时不太稳定也可以通过清华TUNA镜像下载https://mirrors.tuna.tsinghua.edu.cn/apache/maven/maven-3/版本全、速度快和官网文件一致。2.3 Windows 11环境变量配置全过程Windows下我建议把Maven解压到一个独立目录比如D:\apache-maven-3.9.9不要解压到C盘Program Files。原因很简单Program Files目录有时会有权限限制Maven往本地仓库写文件时可能莫名其妙失败。解压完成后配置环境变量右键“此电脑” - 属性 - 高级系统设置 - 环境变量。在“系统变量”里点击“新建”变量名填MAVEN_HOME变量值填你的解压路径D:\apache-maven-3.9.9。找到Path变量双击编辑新增一行%MAVEN_HOME%\bin。注意确认系统里已有JAVA_HOME变量Maven运行时依赖它。没有就新建一个指向你的JDK安装目录。全部确定后新开一个CMD窗口执行mvn -v如果输出类似下面这样就代表安装成功Apache Maven 3.9.9 (8e9479a1b8c9a1a3d0d0e8a5f1f2a3b4c5d6e7f8) Maven home: D:\apache-maven-3.9.9 Java version: 17.0.10, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-17这里有一个新手极易踩的坑执行mvn -v报“不是内部或外部命令”。大概率是Path变量没配好或新变量写错了分隔符。Windows复制路径时要注意别把末尾的反斜杠或者多余空格带进去。2.4 macOS与Linux的快捷安装方式macOS上的安装思路类似只是配置文件路径不同。下载bin.tar.gz后在终端里解压到/opt或你自己定义的目录sudo tar -xzvf apache-maven-3.9.9-bin.tar.gz -C /opt然后编辑~/.zshrc如果用的zsh或~/.bashrc追加export MAVEN_HOME/opt/apache-maven-3.9.9 export PATH$PATH:$MAVEN_HOME/bin执行source ~/.zshrc让配置生效再执行mvn -v验证。Linux同样操作。额外说一个懒人方案macOS用户如果装了Homebrew直接brew install maven就能装完Homebrew会自动配置好环境变量。唯一的坑是Homebrew版Maven的settings.xml路径不在安装目录里需要自己创建或定位后面讲到settings.xml时再细说。3. settings.xml的三座大山本地仓库、阿里云镜像与JDK编译版本Maven装好之后真正决定“好不好用”的是settings.xml。这个文件可以在两个位置全局配置在Maven安装目录的conf/settings.xml用户级配置在~/.m2/settings.xml。用户级配置优先级更高。说句大白话你改了全局配置但用户目录下还有个settings.xml系统会优先读用户的。很多人配置了半天没效果就是这层关系搞混了。3.1 localRepository把默认仓库挪出C盘打开你Maven目录下的conf/settings.xml找到localRepository标签。默认情况下它被注释掉了Maven会用~/.m2/repository作为本地仓库。这个默认位置有两个隐患。第一C盘空间很容易被塞满。Java项目的依赖多跑上两三个项目本地仓库轻松超过1GB如果你用Docker、Node_modules也堆在C盘很快系统盘就报警了。第二一旦系统崩溃需要重装C盘所有jar包缓存全部清零下次构建又得从远程仓库慢慢拉。所以我的建议是把本地仓库挪到一个独立目录比如Windows下的D:\maven-repomacOS/Linux下的/data/maven-repo。localRepositoryD:/maven-repo/localRepository在XML里路径分隔符用正斜杠/最稳妥Windows它也能识别。改完保存执行mvn help:effective-settings可以查看当前真正生效的配置是否生效。3.2 阿里云镜像配置一条配置解决90%的下载失败国内环境最让人头疼的就是从中央仓库下载依赖太慢甚至直接超时。解决办法是配置镜像仓库把请求转发到国内服务器。阿里云提供的Maven公共仓库是最成熟的选择。在settings.xml的mirrors标签里加上mirror idaliyunmaven/id name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url mirrorOf*/mirrorOf /mirrormirrorOf*/mirrorOf的意思是所有仓库请求都走这个镜像。这个配置能让90%的“下载慢”“下载失败”“Could not transfer artifact”问题直接消失。阿里云公共仓库聚合了Maven Central、JCenter、Google等多个公开仓库日常开发完全够用。3.3 多个镜像的优先级与匹配规则有人会问我想同时配阿里云和华为云做冗余备份行不行可以但要注意Maven的镜像匹配逻辑。Maven在同一个仓库请求上只会使用第一个匹配的镜像而不是把所有镜像挨个试一遍。所以如果你写了两个mirrorOf*/mirrorOf永远只有第一个生效第二个形同虚设。更合理的做法是主镜像用阿里云mirrorOf*/mirrorOf兜底一切。如果某个私有仓库不想走镜像用排除语法mirrorOf*,!private-repo/mirrorOf。如果项目里在pom.xml或parent里定义了多个repository又想只对中央仓库走阿里云也可以用精准匹配mirror idaliyun/id mirrorOfcentral/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror中央仓库的ID叫central这样配置只镜像中央仓库其他仓库还是直连。这里面没有绝对的“正确答案”关键是你得清楚mirrorOf的匹配优先级知道自己配出来的行为是什么。3.4 编译版本统一settings里的profile配置还有一个高频报错和settings.xml相关项目在别人机器上编译正常到了你这里就报“invalid target release: 17”。排查一圈发现Maven默认的编译级别不是你项目期望的JDK版本。Maven的默认编译级别通常很低比如JDK 8环境下默认还是1.7。解决办法是在settings.xml里配置一个全局profile用maven.compiler.source和maven.compiler.target指定统一的编译版本profiles profile idjdk-17/id activation activeByDefaulttrue/activeByDefault /activation properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties /profile /profiles这段话的含义是默认激活一个叫jdk-17的profile所有项目的编译源码级别和目标级别统一为17。如果你用的是JDK 8把17改成8即可。这样就能避免每新建一个项目就要手动调编译版本的问题。3.5 一份可以直接抄的settings.xml完整模板把前面几项合起来一份可用的settings.xml长这样?xml version1.0 encodingUTF-8? settings xmlnshttp://maven.apache.org/SETTINGS/1.2.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/SETTINGS/1.2.0 https://maven.apache.org/xsd/settings-1.2.0.xsd localRepositoryD:/maven-repo/localRepository mirrors mirror idaliyunmaven/id name阿里云公共仓库/name urlhttps://maven.aliyun.com/repository/public/url mirrorOf*/mirrorOf /mirror /mirrors profiles profile idjdk-17/id activation activeByDefaulttrue/activeByDefault /activation properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties /profile /profiles /settings保存后执行mvn help:effective-settings你应该能在输出里看到localRepository、mirror和profile都已经被读取。至此Maven的命令行侧配置就算彻底搞定了。4. IDEA集成Maven全局配置与新建项目的正确姿势命令行配好了绝大多数人日常开发还是用IDEA。IDEA里Maven相关配置的坑比命令行多得多而且每个版本之间入口位置还不太一样。4.1 用自己的Maven还是IDEA自带的MavenIDEA内置了一个Maven其实就是一个打包好的Maven目录位于IDEA安装路径下的plugins/maven/lib/maven3。它开箱即用但有个问题IDEA内置Maven的版本往往和官方稳定版有偏差。我强烈建议改为自己安装的Maven原因有两个。第一统一版本命令行执行mvn用的是你手动装的MavenIDEA如果用的是内置版本两边可能在某些行为上有差异排查问题时容易精神分裂。第二看到源码自己装Maven能清楚知道版本号也方便调试。4.2 IDEA配置Maven的三个入口打开IDEA进入File - Settings - Build, Execution, Deployment - Build Tools - Maven你会看到需要配置的三栏Maven home path填你的Maven安装目录比如D:\apache-maven-3.9.9User settings file点后面的Override复选框再填D:\apache-maven-3.9.9\conf\settings.xmlLocal repository点后面的Override填D:\maven-repo这里要重点强调Override复选框。IDEA默认会用它自己识别的settings.xml和本地仓库你如果不勾选Override并手动指定前面在settings.xml里配的阿里云镜像和仓库路径全部不会生效。很多人的问题就出在这一步。改完当前项目配置后还得处理新项目配置。新版IDEA入口变了File - New Projects Setup - Settings for New Projects然后重复上面的路径配置。这样以后每次新建项目IDEA才会默认使用你的配置否则新建项目又会回到IDEA内置Maven的老路上。第三个入口是Runner设置在Build Tools - Maven下的Runner选项卡里。这里有一栏VM Options建议填入-Xms512m -Xmx1024m这是Maven JVM的堆内存配置多模块项目编译时经常因为堆内存不足而失败提前配好能省很多事。4.3 新建Maven项目archetype怎么选、Catalog卡住怎么办在IDEA里新建项目选Maven时通常会出现两个常用archetypeorg.apache.maven.archetypes:maven-archetype-quickstart生成普通Java项目包含java目录、test目录和基础pom.xmlorg.apache.maven.archetypes:maven-archetype-webapp生成Java Web项目带webapp目录和web.xml两种怎么选做普通Java后端服务、基础Java应用选quickstart做需要打成war包部署的Web项目选webapp。快速验证某个功能时我反而建议不选任何archetype直接创建一个空的Maven项目然后在pom.xml里自己写依赖结构更清爽。选完archetype之后很多新人会被一个Loading archetypes卡住半天不出来。这是因为IDEA在联网拉取archetype的目录索引。解决办法是在IDEA的Maven Runner VM Options里加一行-DarchetypeCataloginternal用本地内置的archetype目录代替远程下载几十秒就能进到Next页面。如果你只是偶尔新建项目也可以等它慢慢加载但加了这行参数后体验会快很多。4.4 改完配置不生效多半是Override的锅这块我要单独拿出来说因为踩的人太多了。现象是明明改好了settings.xmlIDEA还是慢吞吞地从国外中央仓库下载jar包。排查步骤按顺序来打开File - Settings - Build, Execution, Deployment - Build Tools - Maven确认User settings file右侧的Override勾选了吗很多教程让你点Override你只是看了没点然后继续填路径等于白填。确认路径写的是不是全局配置conf/settings.xml。如果你填了用户级~/.m2/settings.xml也要保证那个文件里确实有镜像配置。修改pom.xml后记得点IDEA右上角的Reload All Maven Projects按钮一个圆形刷新的图标或按CtrlShiftO。如果还是不放心去IDEA的Help - Edit Custom VM Options确认没有奇怪的Maven配置覆盖掉你的设置。这套检查做完90%的“配置不生效”问题都能解决。5. 高频翻车现场依赖爆红、下载失败、Oracle驱动缺失配置阶段完成后真正影响日常开发的还是各种运行时问题。我挑几个高频问题按排查链路来讲。5.1 依赖爆红的排查顺序IDEA里pom.xml的依赖爆红优先级从高到低按下面顺序排查第一步看它有没有在下载。如果右下角有进度条在走说明只是在下载慢稍等即可。一直不动就要怀疑镜像配置没生效。第二步检查坐标是否正确。去https://mvnrepository.com/搜索对应的groupId和artifactId看看你写的版本号存不存在。很多爆红其实就是坐标写错了常见的是版本号拼写错误比如2.5.7写成2.5.6而那个版本压根不存在。第三步检查本地仓库有没有生成lastUpdated文件。打开你的本地仓库目录如果发现一堆xxx.jar.lastUpdated文件说明之前的下载失败了。处理办法见下一小节。第四步命令行强制执行一次。在项目根目录执行mvn clean compile -U-U会强制更新快照和远程元数据。如果命令行能成功但IDEA里还红重启IDEA或清理缓存File - Invalidate Caches / Restart。多模块项目还有另一种情况A模块依赖B模块B模块改了代码但没执行mvn installA模块引用的还是本地仓库里的旧版本。这种爆红和网络无关本质是本地仓库没有最新产物。解决办法是先mvn install一下被依赖的模块。5.2 jar包下载一半失败lastUpdated文件与-U参数Maven下载依赖时如果中途断网、被中断、或者镜像源临时抽风会在本地仓库里留下一个.lastUpdated文件。这个文件非常坑它是Maven用来标记“上次下载失败时间点”的。默认情况下Maven在一段时间内不会再次尝试下载这个失败文件对应的jar于是IDEA里会一直爆红你刷新多少次都没用。解决办法有两种。一种是执行强制更新命令mvn clean compile -U另一种是直接清理所有lastUpdated文件Linux/macOSfind ~/.m2/repository -name *.lastUpdated -deleteWindows PowerShellGet-ChildItem -Path $env:USERPROFILE\.m2\repository -Recurse -Filter *.lastUpdated | Remove-Item清理完以后再重新Reload Maven项目基本都能恢复。5.3 mvn编译内存溢出MAVEN_OPTS怎么配置大型多模块项目编译时偶尔会看到这样的报错java.lang.OutOfMemoryError: Java heap space这就是Maven构建JVM的堆内存不够了。解决办法是设置MAVEN_OPTS环境变量。Windows临时设置set MAVEN_OPTS-Xms512m -Xmx2048mmacOS/Linux临时设置export MAVEN_OPTS-Xms512m -Xmx2048m也可以在IDEA的Maven Runner VM Options里配置这样只对IDEA内的构建生效-Xms512m -Xmx2048m如果你用IDEA还遇到java.lang.OutOfMemoryError: PermGen space之类的老报错在Maven编译和测试时加上-XX:MaxMetaspaceSize512m也很有效。写成完整格式就是-Xms512m -Xmx2048m -XX:MaxMetaspaceSize512m5.4 Oracle驱动在中央仓库找不到坐标从哪来装去哪个仓库热搜里有个词我很眼熟“maven项目连接Oracle数据库、缺少driver从哪里下载”。这个问题的历史包袱很重。在Maven Central上Oracle的JDBC驱动一度很难搜到。早期教程大家都用com.oracle.jdbc:ojdbc8但这个坐标在中央仓库里根本不存在所以依赖永远爆红。后来Oracle把驱动发布到了Maven Central正确坐标应该是dependency groupIdcom.oracle.database.jdbc/groupId artifactIdojdbc8/artifactId version19.8.0.0/version /dependency注意groupId是com.oracle.database.jdbc不是com.oracle.jdbc。这是很多老教程已经过时的地方。如果你用的还是那种从Oracle官网手工下载的jar包不打算走中央仓库也可以手动安装到本地仓库mvn install:install-file \ -Dfileojdbc8.jar \ -DgroupIdcom.oracle.database.jdbc \ -DartifactIdojdbc8 \ -Dversion19.8.0.0 \ -Dpackagingjar这条命令执行完jar就被装进本地仓库之后pom.xml里就能正常引用了。这条路也适用于任意私有jar包比如公司内部SDK、第三方加密库等。5.5 几个高频命令行指令速查命令行和IDEA配合使用效率会高很多。下面这几个命令是我几乎每天都要用的命令作用mvn clean清理target目录mvn compile编译源码mvn test运行测试mvn package打包jar/warmvn install安装到本地仓库mvn deploy发布到远程仓库/私服mvn dependency:tree查看依赖树排查依赖冲突神器mvn dependency:resolve强制解析所有依赖mvn help:effective-settings查看当前生效的settings.xml内容mvn help:effective-pom查看当前生效的pom.xml内容其中help:effective-settings和help:effective-pom是我特别想推荐的。很多人纠结“我明明配了为什么没生效”这两个命令直接把“生效后的真实配置”打给你看什么问题都藏不住。6. 装好只是开始私服、上传中央仓库与Maven习惯把Maven跑起来只是第一步。在公司里干过一两年你大概率会遇到私服和发布的问题。这块不算新手必学但理解了能让你对Maven的理解上一个台阶。6.1 团队内网为什么需要Nexus私服假设你们公司有几十个后端服务都用Maven管理依赖。如果不搭私服每个人每次构建新环境都要去公网拉一遍依赖慢不说万一某个依赖临时被发布者删掉或版本重写团队几百号人直接全部踩坑。私服最常见的实现是Sonatype Nexus或Artifactory相当于团队内部的一个Maven仓库中转站。它的作用有三层代理远程仓库把下载过的jar缓存在内网存放公司内部的私有jar包其他项目通过私服引用发布快照版本Snapshot方便多服务联调Nexus 3的安装非常简单去官网下载对应系统的压缩包解压后执行bin/nexus start默认访问端口8081。然后在Nexus后台创建一个Maven2仓库拿到仓库地址回到Maven settings.xml里配置server idnexus-releases/id usernameadmin/username password你的密码/password /server再配一个镜像或直接在pom.xml的distributionManagement里指定发布地址。这样整个团队的依赖就能走内网了。6.2 把自己的jar包上传到中央仓库的完整路径如果你写了一个不错的开源工具想让全世界的Java开发者都用mvn dependency引进来就需要把jar包发布到Maven Central。这条路我第一次走的时候花了两天核心步骤理清楚如下注册Sonatype OSSRH账号并创建一个Issue申请你的groupIdgroupId通常是你拥有的域名的反写例如io.github.yourname。等待审核通过一般1~2天。在项目pom.xml里配置分发仓库地址、开发者信息、许可证等信息。生成GPG密钥对jar包和pom文件做签名公钥上传到GPG服务器。配置~/.m2/settings.xml里的服务器账号密码。执行mvn clean deploy发布到Sonatype的Staging仓库。在Sonatype后台点击Close并Release等待同步到中央仓库一般几个小时到一天可见。整个过程不算难但门槛在于是不是第一次。第一次弄明白后后续发版本就只是重复执行而已。如果你的项目只是公司内部用完全不必折腾中央仓库搭个Nexus私服把mvn deploy指向私服就够了。6.3 我的几个Maven使用习惯最后分享几个我多年养成的Maven使用习惯谈不上高深但很实用。第一所有新项目统一从同一个settings.xml出发。我会把一份配置好的settings.xml放在公司内网的公共知识库里新人入职直接复制到自己电脑改一下localRepository路径即可。既避免每个人配出不同花样也方便出问题时对比排查。第二每到一个新环境第一件事先执行mvn help:effective-settings。看看当前生效的镜像和本地仓库到底是谁这一步比反复刷新IDEA高效得多。第三遇到依赖冲突时不要凭感觉猜用mvn dependency:tree看清楚依赖树。最常见的冲突就是Spring Boot和某些老框架的传递依赖版本不一致树上能看到两个不同版本再用exclusions排除掉不合适的那个比盲目升降版本号要靠谱得多。第四pom.xml里的dependencyManagement是神器。在多模块项目里把统一的依赖版本号抽到父pom里子模块只写groupId和artifactId。这样升级依赖时只改一处不会出现各模块Arc版本不一的情况。我在实际带团队时还有个小习惯本地仓库目录可以放在固态硬盘以外的独立分区但不要放在网络磁盘上。网络磁盘IO延迟高编译时大量读写本地仓库会明显拖慢构建速度。这个坑我踩过一次换了本地目录后构建时间直接降了一半。Maven这个工具说透明了并不复杂但配置链路里的小坑一个接一个。好在这条路上的“坑位”基本是固定的只要把版本兼容、settings.xml加载路径、镜像配置、IDE Override这几件事搞清楚剩下就是日常的重复使用和经验积累了。如果你现在卡在某个Maven报错上不妨先按着文章里的排查顺序走一遍多数问题在help:effective-settings这一步就会真相大白。
返回列表