目录

spring-ai-alibaba-examples项目编译运行

spring-ai-alibaba-examples项目编译&运行

编译

软件

mac-m芯片arm架构

maven-3.9.9

IDEA-2023.3.8

JDK-17(zulu17.56.15)

IDEA设置

工程设置

https://i-blog.csdnimg.cn/direct/305161fce89f413ab198f5f28916a672.png https://i-blog.csdnimg.cn/direct/416e8d3942ba46459f9d05a5fec10e63.png

maven设置

https://i-blog.csdnimg.cn/direct/a7a9019349444e1f9c3f6f25d2292f2c.png

https://i-blog.csdnimg.cn/direct/004924ecc3c345eabb358b84561f3092.png

https://i-blog.csdnimg.cn/direct/7112739d9c0742cc98db39fa8e33d000.png

Compiler设置

https://i-blog.csdnimg.cn/direct/a008d5b567e2462e92aec5789f5dcf36.png

https://i-blog.csdnimg.cn/direct/581f3633bdb44acb922f8c0dfc4437c7.png

执行编译

注意观察执行的命令是否是配置的maven+settings.xml、jdk等,本人就碰到了个坑明明上述配置都完成了的,但执行clean、compile等时候却使用 默认配置 ,导致编译失败

默认配置 :

1、我本身系统使用brew安装了jdk8,也配置了JAVA_HOME等变量。这样IDEA会直接读到这个jdk路径作为默认的jdk(有点像Spring的约定大于配置的思想)实际上很多软件都会尝试自动读环境变量JAVA_HOME的配置(MAVEN_HOME也是如此)

而这个工程要求jdk版本17以上,因此不得不下载一个tar形式的jdk(但不对其做任何环境变量的配置,只是找个目录解压下来就行),然后仅对这个项目使用该jdk17

2、maven是下载的tar形式的3.9.9版本,其conf目录下有个settings.xml文件

这里又是约定大于配置的思想,在默认情况下若IDEA等工具配置maven时,会使用其conf下的settings.xml,而这个xml文件你不修改的它的话,在maven运行时又会有默认配置,比较关注的是

1)本地仓库localRepository:默认为【xxxxx/.m2/Repository】

2)远程仓库mirror:默认为【 】

这俩值不改的话会有一些痛苦的事情:编译时巨慢(因为从远程仓库里下载jar包太慢了);时间久了c盘要爆炸(因为上述.m2路径是在用户路径下,如果是windows电脑就在C盘里)

因此不管什么姿势使用maven时,都先把conf/.settings.xml文件里的这俩值改一下,远程仓库建议直接用aliyun,本地仓库本人一般是放在【xxx/xxx/repositories/default/Repository】

https://i-blog.csdnimg.cn/direct/137687e0a4e548c6832ce56c383b6473.png

再回到本次项目,公司一般会有自己的maven配置,那又希望这个项目用一个本地仓库、公司用一个本地仓库,其实思想类似python工程的 Virtualenv Environment 是类似的

https://i-blog.csdnimg.cn/direct/8674d8ca57be426a9cea7da538190992.png

这里我配置了3个settings文件,一个默认使用,一个公司项目使用,一个是单独为这个项目编译使用,互不影响

注意事项

在执行maven命令时,一定要注意所使用的命令是否是自己期望的,否则会有一些奇奇怪怪的错误

https://i-blog.csdnimg.cn/direct/7574b1fa250e480790dd61fba27c8405.png

运行

maven依赖冲突

这是比较头疼的一件事情,依赖冲突本身概念简单但会碰到各种各样奇怪的事情:

编辑期 & 编译期

先说可能会碰到什么样的现象

1、Run maven clean install成功(即使用maven没问题)但代码就是报错,而且是那种不点开这个代码文件就不会报错,但只要一点开就报错,刷新后文件夹不报错但点开文件又报错

1)可能是IDEA自身索引问题,用的时间比较久了、项目比较大文件很多:可以使用更新版本的IDEA、Reload All Maven Projects、Repair IDE、Invalidate caches等

2)可能maven 依赖冲突 (随着IDEA工具越来越完善,但是公司项目代码和依赖越积越多,这个情况才是碰到最多)

这种比较好排查,代码里报错的不认识的标识符会显示【Cann’t no resolve xxx】然后import位置会是灰色+红色,类似下面这样

https://i-blog.csdnimg.cn/direct/18295a7a5d954c82a006a0ac06396f3c.png

点开灰色的model可以定位到项目的本地依赖(注意是 本地依赖 ,这里为啥要强调呢?留个悬念)

但是困惑的是,在我们IDEA里显示这个类明明是有的啊

原因:公司项目一般是使用专门的文件统一管理依赖的字段的,一般不同项目都不会自己管理version,而二方包相互依赖不同业务可能使用一些共同包升级节奏不同,非常容易造成对一些基础包的依赖版本不同,比如公司提供一个common-utils包,而某个业务方使用了最新的但某些业务方却使用旧的,这样当相互依赖时就会导致版本冲突

解决方案:其实是在增加pom依赖的过程中没有遵循好的规范导致的,比如api包应该干净,不应该依赖任何包(然而很少有做到这一点的)等等

临时方案:

3)本地依赖无法覆盖

现在回答一下上面的本地依赖问题:

当我们执行maven clean install时,会向我们本地仓库里写入一个jar包文件

当我们构建工程时,若本地仓库没有会从公司maven仓库里下载到本地仓库里

首先这里有个原则是

运行期

这种情况比较少碰到,我已经没有截图证据了,印象当中是代码编辑、编译、构建jar包、程序启动等过程全都没问题,但偏偏就逻辑执行到时报一些ClassNotFound、方法未找到等错误,拉最新代码来看又看不出问题(因为本地看代码使用的是电脑本地仓库,IDEA报不报错除了依赖你本地仓库外,还有自己的代码索引);当时是通过arthas命令看目前正在运行的jar包所载入的依赖jar包版本、类路径等,才发现其依赖的二方包未更新