我真服了，昨晚搞到凌晨。
明明是按照教程一步步去做的，PATH也进行了配置，/etc/profile也执行了source操作，可是mvn -v却总是报那个JAVA_HOME不正确。后来经过一番查找才发现，JDK21不存在JRE文件夹，而mvn.cmd这个脚本它很愚蠢啊它居然不认识。
前往maven安装场所的bin区域之内，以右键点击mvn.cmd，而后进行编辑操作。
转变至最上方，强行塞入一行，内容为 set JAVA_HOME=C:Program FilesJavajdk - 21。
保存，再敲 mvn -v
那个瞬间看到版本号刷出来，像憋了三个小时的尿终于找到厕所。
为啥非要折腾这个？
其实Eclipse自带了Maven，但你懂的，它那个版本。
就像是酒店里一次性牙刷，能刷，但刷不干净 。
版本低得不行，插件兼容器全是些让人头疼的问题，有时明明依赖就在中央仓库，可它却偏偏说找不到，气得简直想把鼠标给摔了。
所以我必须在/usr/local/下面塞一个3.8.8。
解压，复制，改环境变量。
/etc/profile 这个文件，在进行修改着的时候，总是会让人感觉好似正处于做手术的状态，一旦要是敲错了哪怕仅仅一个字母，那么该系统无法正常启动进而就会导致事情变糟糕了。
maven 的配置文件在哪里找？
在 $MAVEN_HOME/conf/settings.xml 这里面的，是全局的。
用户级在 ~/.m2/settings.xml
后者优先级更高 。
我建议你配用户级的。
由于公司所配备的电脑，倘若哪一天有其他人将你整个局面的内容进行了更改，当你对项目进行一次打包操作时，呈现出来的全部都是红叉。
还有，改之前记得备份。
我头一回进行学习之际，将settings.xml书写得满是语法方面不对之处，maven全然停止运作，在那瞬间真的特别想要转换行当去送外卖。
现在养成的毛病：
将设置文件，复制为备份文件，把设置文件，命名为设置备份文件。
——这行命令打出来，心里才踏实。
怎么让下载速度嗖嗖的？
阿里云镜像，yyds。
以前从中央仓库拉一个spring-core，四分钟。
配完镜像，四秒。
那种感觉怎么形容呢。
如同往昔于火车之上等待泡面那个水烧开，随后乘坐了高铁，饮料瓶盖尚未拧开之时就已然到达站点了。
配置代码我也懒得背，每次都翻收藏夹：
aliyunmaven
central
阿里云公共仓库
https://maven.aliyun.com/repository/public
放进去，保存。
从此告别“Downloading…”时的心跳加速。
IDEA里为什么又要配一遍？
这个问题我室友问过我。
他觉得既然电脑都认得mvn命令了，IDEA就应该自动认啊。
不是的。
IDEA是IDEA，系统是系统。
它们是两个世界的人，需要有人介绍才能认识 。
那么，你务必处在 File -> Settings -> Build, Execution, Deployment -> Build Tools -> Maven 的设置当中：
路径为Maven的家，选择会自己选择已解压的文件夹里带有3.1和8.8的那个文件夹。
用户设置文件，将覆盖选项勾选上，选择刚才修改好的设置文件.xml。
本地存储库：它能够自行读取配置文件之中的路径，无需进行操作。
不做这一步，你配置一整晚的阿里云镜像，在IDEA那看来就如同不存在似的。
关于那些命令，我一直记混
clean：
将target文件夹予以删除，如果代码有时候会在毫无缘由的情况下出现报错现象，那就进行clean操作，如此一来，世界便归于安静状态了。
compile：
.java变.class。
如果只想检查语法错误，用这个最快 。
test：
跑单元测试。但我经常偷懒。
mvn package，通过-DskipTests这个参数来实行相关操作，此操作的目的是跳过测试，不过却要编译测试代码。
mvn 打包，通过设置 -Dmaven.test.skip=true 来实现，这意味着会彻底跳过，连测试代码都不会进行编译。
第二种比较暴力，我一般周五下午用。
package：
打成jar或war。
它与install之间存在着怎样的区别呢，对此我先前记了之后又忘却了，忘却之后又再次去记，如此这般循环往复历经了三四年的时间。
后来一个老哥说人话讲给我听：
封装：告知你“已进行打包装束，放置于你项目的目标位置之中了”。
进行安装操作，将其进行打包处理，然后放置一份到你电脑的本地仓库之中，向电脑传达“老子这个安装包不要删除，因为别的某个项目会用到它”这样一条信息。
deploy：
这是公司里用的。发到私服，别人才能拉。
昨天遇到个奇怪的错
Provider模块已经完成编译，然而Consumer模块却始终咬定找不到相关依赖，怎么都不行。
明明在同一个父pom下，父pom里也写了module。
后来去查，发现是：
Consumer对Provider存在依赖，然而Provider尚未进行install。
本地的仓库当中，压根就不存在Provider的jar，Consumer自然是寻觅不到的。
在到达Provider目录之后，执行mvn clean install。
然后Consumer那边就通了。
这种问题特别傻，但几乎每个月都会犯一次。
大概，这便是我与Maven的一种彼此之间的相处模式了，它，对我进行了千百次的虐待，而我，却始终像对待初恋那般，对待着它。
其实Maven挺温柔的
刚开始学的时候，觉得这家伙规矩真多。
项目的目录结构是不可以随意变动的，groupId必不可少，artifactId绝对不能缺少也不能有误改，version同样一个都不能少，而且有时候哪怕只是一个标签的顺序出现了错误，整个项目就会呈现出错报红的状况。
可随后项目数量增多了，存在的依赖也变多了，十几个模块之间相互进行调用，依靠手动方式去管理jar包，那简直会让人崩溃的。
版本冲突、依赖传递、传递过来的版本又冲突……
那种时候你会发现，Maven脾气虽然臭，但它不乱来。
它逼你守规矩，最后其实是保护你。
好了，又扯远了。
之前要记得先去备份settings.xml，然后再去配置镜像，最后借助mvn -v进行验证一下。
如果JAVA_HOME报错，试试我刚才说的那个笨办法。
晚安。
写代码的人不应该熬夜。
Comments NOTHING