这特么是个老问题了，深夜还在改pom，我知道你。
凌晨时分零点整，窗外到处都是一片寂静无声，IDEA右下角那里的那个蓝色进度条转动起来好似心电监护仪一般。
原本在本地运行得顺顺当当的，可一旦进行打包操作，就立马出现了 NoClassDefFoundError 这种状况，气得人简直想要把键盘给砸了。
快递鸟、支付宝、微信。总有些 SDK 长在中央仓库外面。
像个没户口的婴儿。
中央仓库？算了，惹不起
那套流程你打开过三次，然后关了三次。
创建工单、生成秘钥、签名、验证、等审核。
为了一个破 jar，感觉要给 Maven 写入党申请书 。
算了，何必呢。
私服？小庙供不起大佛
Nexus 是挺好，但咱就一个破项目，还要专门搞台服务器？
老板会觉得你要造反，想自己搭个“企业级基础设施”。
然后这台服务器还得你管，包是你传的，锅是你背的。
传统方式，最熟悉的陌生人
新建的lib目录，通过同时按住ctrl键与c键，再按住ctrl键与v键，之后添加为库。
三秒搞定，亲切得像回到大学写作业 。
直到同事发消息：
“你那个包在哪下的？我这儿标红。”
“你把你 lib 文件夹发我。”
“还是不行，你过来帮我看看吧。”
烦死了。比写代码还烦。
重点说说第四种，scope=system
这是大多数人的“终点站”。
system
${project.basedir}/lib/xxx-sdk.jar
看着特干净，对吧 。
编译过了，不报红了，摸鱼了。
然后准备上线，打包。
卒。
Boot - INF/lib 之中是空荡荡的，压根就没有将那个坏掉的 jar 给装进去。
你在本地能够运行，是由于IDE在classpath里直接指出了那个路径。
服务器不认识你的 C 盘 。
要加 resource，要配 include。
碰运气欠佳的状况下，居然还得去调整那个maven - dependency - plugin，真是让人头疼。
一个本应简单的“把文件放进去”，硬生生写成兵法 。
我其实最懂的是第五种
你原文说第五种“差异性太大，不推荐”。
但我懂你，你试过。
mvn install:install-file。
那个命令你背都背下来了。
-DgroupId-，-DartifactId-，-Dversion和Dfile。
按下回车之后，目睹BUILD SUCCESS，内心安稳了短暂的一秒钟。
紧跟着就寻思：此刻这包处于我的.m2 之内，那同事那里该如何是好呢？Jenkins 那里又该如何处理呢？
总不能让我半夜挨个 ssh 上去敲命令吧。
dingding
dingding
2.8
system
${project.basedir}/lib/taobao-sdk-java.jar
所以，最终确定下来的是选取了第四种，而后再去安安静静地把那几行数目的resource给补上。
lib 文件夹打进 jar 里。
像个笨办法，但能睡着。
后来我发现，这才是常态
2026年已然到了，众人都在谈论Gradle，众人都在谈论Nix Flakes，众人都在谈论构建即代码。
好像再碰这些本地 jar 就是技术耻辱。
但现实是：
银行的合作方只发给你一个十年没更新过的 jar。
外包对接的硬件厂商，SDK 写死在光盘里。
你明明清楚这种这些依赖是毫无可用价值只会给人带来困扰之物，你却依旧要把它给吃下肚去，并且要用 Maven 去掺和搅拌均匀，使之相互结合。
那些漂亮的构建工具，这时候都帮不上忙。
lib
/BOOT-INF/lib/
**/*.jar
把 jar 放进 lib 文件夹的那一瞬间
你会有种奇怪的感觉。
好似倒退回到了二零零五年，那时并不存在中央仓库，众人皆是这般复制来复制去。
但我们不就是干这个的吗。
dingding
dingding
2.8
system
${project.basedir}/lib/taobao-sdk-java-auto_1479188381469-20190628.jar
lib
/BOOT-INF/lib/
**/*.jar
在完美的标准和糟糕的现实之间，当一个翻译官。
现在 jar 已经放进去了，pom 也改完了。
打包命令正在跑。
今晚的 Bug 会在今晚结束。
明天还有明天的包要引。
Comments NOTHING