在 Maven (2004)、Gradle (2012) 甚至 Ant (2000) 出现之前Java 程序员的日子可以用“硬核”、“手工”和“充满仪式感”来形容。那个时代没有统一的构建工具依赖管理基本靠“人肉”打包部署全靠手写脚本。如果你穿越回 1998 年做一个 Java 项目你的日常大概是这样的依赖管理靠“共享文件夹”和“ZIP 包”那时候没有中央仓库Maven Central 是后来才有的也没有 pom.xml 或 build.gradle。物理介质最原始的方式是拿着软盘或光盘去拷贝 servlet.jar、jdbc.jar。共享文件夹团队里通常会有一个“老大哥”负责收集所有第三方库放在一个共享的 NAS 或 FTP 服务器上。新人入职的第一件事就是把这个巨大的文件夹拷到本地。版本地狱没有版本号规范。你的文件夹里可能同时存在 log4j.jar、log4j-1.2.jar、log4j-new.jar。谁也不知道哪个是最新的只能靠文件名或者打开 README.txt 看日期。提交到 CVS很多团队简单粗暴地把所有 .jar 文件直接提交到 CVS/SVN 版本库里导致仓库极其臃肿Checkout 一次要半小时。编译与构建Shell/Bat 脚本 或 Makefile没有 mvn compile你需要自己告诉编译器去哪找类。手写脚本你会写一个 build.sh 或 build.bat。内容大概是这样的# 噩梦开始CLASSPATH“lib/servlet.jar:lib/jdbc.jar:lib/log4j.jar:classes”javac -classpath $CLASSPATH -d classes src/com/myapp.java src/com/myapp/util/.java# 如果文件太多javac 参数列表会爆掉还得用 argfile 这种技巧Makefile因为 Java 太早很多 C/C 程序员习惯用 make 来构建 Java但 Make 的依赖追踪对 Java 来说很痛苦尤其是内部类、匿名类生成的 .class 文件。IDE 绑定很多人干脆不写脚本直接在 Visual Age for Java、JBuilder 或早期的 Eclipse 里点 “Build”。结果就是“在你机器上能跑在我机器上报错”因为 IDE 的配置没同步。打包jar 命令与 Manifest 的博弈没有 mvn package你需要手动组装 WAR/JAR。手动复制写脚本把编译好的 .class 复制到 WEB-INF/classes把 .jar 复制到 WEB-INF/lib把 .jsp 和 .xml 复制过去。打 JAR 包jar cvfm myapp.jar MANIFEST.MF -C classes .Manifest 陷阱这是最让人崩溃的环节。如果你忘了在 MANIFEST.MF 里写 Class-Path或者路径写错了一个空格程序启动就会报 ClassNotFoundException。而且 jar 命令不会告诉你错在哪只会默默失败或抛出奇怪的异常。部署FTP 与 重启大法没有 Docker没有 CI/CD没有 Tomcat 热部署。FTP 上传用 CuteFTP 或 WS_FTP把打好的 myapp.war 传到服务器的 /opt/tomcat/webapps。停止服务kill -9 或者运行 shutdown.sh。清理缓存手动删除 work 目录和 temp 目录防止旧代码缓存。启动服务运行 startup.sh。看日志tail -f catalina.out祈祷不要看到 OutOfMemoryError 或 Port already in use。回滚如果炸了赶紧把备份的 myapp.war.bak 传回去重复上述步骤。那个时代的“神器”与“痛点”IDE 是救命稻草也是万恶之源JBuilder、Visual Age for Java、WebLogic Workshop 是当时的霸主。它们内置了构建逻辑帮你管理 Classpath。痛点项目配置和代码强耦合。换个 IDE重写配置。换个人配置冲突。应用服务器极其昂贵那时候 WebLogic、WebSphere 是主流License 按 CPU 核数卖几十万美金起步。开发环境通常是这些重型服务器的“开发版”启动一次要 2-3 分钟。Tomcat 当时还是“轻量级替代品”很多大厂不敢用。没有单元测试的“黄金时代”JUnit 3 刚出来不久配置极其繁琐需要继承 TestCase方法名必须 test 开头。因为构建太慢跑一次全量测试要 10 分钟大家根本不敢频繁跑测试。测试基本靠部署到服务器 - 打开浏览器 - 点点点。总结从“手工作坊”到“流水线”在 Ant 出现之前Java 开发就像在自家厨房做饭菜依赖要去菜市场买FTP下载买回来还要洗切解压、整理。锅Classpath要自己架火JVM参数要自己调。做好了装盘JAR/WAR端给客人部署客人说咸了你得倒掉重做。Ant (2000) 的出现相当于给了你一套标准化的厨房工具虽然还是要自己写菜谱XML 巨长但至少锅碗瓢盆是统一的。Maven (2004) 的出现相当于中央厨房 预制菜你不用去买菜了依赖自动下载。你不用切菜了约定优于配置。你只管最后加热装盘写业务逻辑。所以现在的 Java 程序员如果抱怨“Maven 依赖冲突好烦”建议去看看 20 年前的 build.sh你会觉得现在的烦恼简直是幸福的烦恼。 要不要我帮你梳理一下 Maven 和 Gradle 的核心区别毕竟现在新项目基本都在用 Gradle 了。
Maven/Gradle/Ant 出现前：远古 Java 程序员怎么开发、打包、部署的
在 Maven (2004)、Gradle (2012) 甚至 Ant (2000) 出现之前Java 程序员的日子可以用“硬核”、“手工”和“充满仪式感”来形容。那个时代没有统一的构建工具依赖管理基本靠“人肉”打包部署全靠手写脚本。如果你穿越回 1998 年做一个 Java 项目你的日常大概是这样的依赖管理靠“共享文件夹”和“ZIP 包”那时候没有中央仓库Maven Central 是后来才有的也没有 pom.xml 或 build.gradle。物理介质最原始的方式是拿着软盘或光盘去拷贝 servlet.jar、jdbc.jar。共享文件夹团队里通常会有一个“老大哥”负责收集所有第三方库放在一个共享的 NAS 或 FTP 服务器上。新人入职的第一件事就是把这个巨大的文件夹拷到本地。版本地狱没有版本号规范。你的文件夹里可能同时存在 log4j.jar、log4j-1.2.jar、log4j-new.jar。谁也不知道哪个是最新的只能靠文件名或者打开 README.txt 看日期。提交到 CVS很多团队简单粗暴地把所有 .jar 文件直接提交到 CVS/SVN 版本库里导致仓库极其臃肿Checkout 一次要半小时。编译与构建Shell/Bat 脚本 或 Makefile没有 mvn compile你需要自己告诉编译器去哪找类。手写脚本你会写一个 build.sh 或 build.bat。内容大概是这样的# 噩梦开始CLASSPATH“lib/servlet.jar:lib/jdbc.jar:lib/log4j.jar:classes”javac -classpath $CLASSPATH -d classes src/com/myapp.java src/com/myapp/util/.java# 如果文件太多javac 参数列表会爆掉还得用 argfile 这种技巧Makefile因为 Java 太早很多 C/C 程序员习惯用 make 来构建 Java但 Make 的依赖追踪对 Java 来说很痛苦尤其是内部类、匿名类生成的 .class 文件。IDE 绑定很多人干脆不写脚本直接在 Visual Age for Java、JBuilder 或早期的 Eclipse 里点 “Build”。结果就是“在你机器上能跑在我机器上报错”因为 IDE 的配置没同步。打包jar 命令与 Manifest 的博弈没有 mvn package你需要手动组装 WAR/JAR。手动复制写脚本把编译好的 .class 复制到 WEB-INF/classes把 .jar 复制到 WEB-INF/lib把 .jsp 和 .xml 复制过去。打 JAR 包jar cvfm myapp.jar MANIFEST.MF -C classes .Manifest 陷阱这是最让人崩溃的环节。如果你忘了在 MANIFEST.MF 里写 Class-Path或者路径写错了一个空格程序启动就会报 ClassNotFoundException。而且 jar 命令不会告诉你错在哪只会默默失败或抛出奇怪的异常。部署FTP 与 重启大法没有 Docker没有 CI/CD没有 Tomcat 热部署。FTP 上传用 CuteFTP 或 WS_FTP把打好的 myapp.war 传到服务器的 /opt/tomcat/webapps。停止服务kill -9 或者运行 shutdown.sh。清理缓存手动删除 work 目录和 temp 目录防止旧代码缓存。启动服务运行 startup.sh。看日志tail -f catalina.out祈祷不要看到 OutOfMemoryError 或 Port already in use。回滚如果炸了赶紧把备份的 myapp.war.bak 传回去重复上述步骤。那个时代的“神器”与“痛点”IDE 是救命稻草也是万恶之源JBuilder、Visual Age for Java、WebLogic Workshop 是当时的霸主。它们内置了构建逻辑帮你管理 Classpath。痛点项目配置和代码强耦合。换个 IDE重写配置。换个人配置冲突。应用服务器极其昂贵那时候 WebLogic、WebSphere 是主流License 按 CPU 核数卖几十万美金起步。开发环境通常是这些重型服务器的“开发版”启动一次要 2-3 分钟。Tomcat 当时还是“轻量级替代品”很多大厂不敢用。没有单元测试的“黄金时代”JUnit 3 刚出来不久配置极其繁琐需要继承 TestCase方法名必须 test 开头。因为构建太慢跑一次全量测试要 10 分钟大家根本不敢频繁跑测试。测试基本靠部署到服务器 - 打开浏览器 - 点点点。总结从“手工作坊”到“流水线”在 Ant 出现之前Java 开发就像在自家厨房做饭菜依赖要去菜市场买FTP下载买回来还要洗切解压、整理。锅Classpath要自己架火JVM参数要自己调。做好了装盘JAR/WAR端给客人部署客人说咸了你得倒掉重做。Ant (2000) 的出现相当于给了你一套标准化的厨房工具虽然还是要自己写菜谱XML 巨长但至少锅碗瓢盆是统一的。Maven (2004) 的出现相当于中央厨房 预制菜你不用去买菜了依赖自动下载。你不用切菜了约定优于配置。你只管最后加热装盘写业务逻辑。所以现在的 Java 程序员如果抱怨“Maven 依赖冲突好烦”建议去看看 20 年前的 build.sh你会觉得现在的烦恼简直是幸福的烦恼。 要不要我帮你梳理一下 Maven 和 Gradle 的核心区别毕竟现在新项目基本都在用 Gradle 了。
