Java-Maven详解

新手入门Maven，项目构建总出错，到底哪里不对劲？

最近开始学Java Web，老师讲到了Maven，说这个工具现在几乎是做Java项目的标配。刚开始我以为就是个下载jar包的东西，结果自己动手一试才发现，光是创建个项目就遇到一堆报错，搞得我头都大了。

先是环境变量配置，JAVA_HOME、MAVEN_HOME一个都不能少。装完打开命令行输mvn -v，看到版本信息才算第一步走通。但真正麻烦的是，每次编译都提示“源选项5不再支持”，查了半天才知道是JDK版本问题。我电脑上装的是JDK13，而Maven默认配置还卡在很老的版本上。

解决办法有两个，一个是改项目的pom.xml，另一个是改maven安装目录下的settings.xml。我选了改全局配置，加了一段profile，把编译版本指定成13，再跑mvn compile终于不报错了。不过后来发现IDEA里也有自己的Maven设置，还得再同步一遍，不然还是会有冲突。

创建Maven项目也有几种方式。一种是手动建文件夹，按标准结构搭好src/main/java和src/test/java这些目录。另一种是用命令行生成模板，比如mvn archetype:generate加上一堆参数，能直接生成基础项目。最方便的是用IDEA点几下就搞定，但它有时候不会自动创建resources目录，得自己手动补上，还要右键设成资源目录，不然配置文件读不到。

依赖管理这块，以前我们项目里都是把jar包整个复制进去，一个包换版本就得全改，特别麻烦。现在只要在pom.xml里写上groupId、artifactId和version，Maven自己去仓库下载。第一次下完存在本地，别的项目用同一个版本就不用再下了，省流量又省空间。

但依赖也不是完全省心。比如junit这个测试框架，你加上去之后，它还依赖别的包，Maven会自动把那些传递依赖也拉下来。可有时候不同库用了同一个包的不同版本，就会冲突。Maven有个“路径最短优先”的规则，谁离项目近就用谁的。如果同级，就看谁在pom里写在前面。还有optional和exclusions这种高级用法，可以控制依赖是否传递出去，不过我现在还没用到那么深。

项目打包的时候，mvn package会自动先跑测试，test失败就打不了包。这本来是好事，保证质量。但有时候我只是想快速打个包看看，测试还没写完，就不想让它卡在这儿。可以用mvn package -DskipTests跳过测试，或者在pom里配个插件，直接把skipTests设成true。

Maven的生命周期我一开始没搞懂，后来才明白它其实是一串固定流程。比如clean会删target目录，install会把包装进本地仓库，让别的项目能引用。最常用的就是default这个生命周期，从compile到deploy，每一步都环环相扣。你运行mvn install，它前面的编译、测试、打包都会自动执行一遍。

多模块项目也是Maven的强项。比如一个电商系统，分用户、订单、商品几个模块，可以建一个父项目统一管依赖版本，子模块各自开发。用mvn -pl module-user install就能只装某个模块，调试起来方便多了。

公司里一般都有开发、测试、生产三套环境，数据库地址都不一样。每次都手动改配置太麻烦。Maven有profiles机制，可以在pom里定义不同的环境配置，打包时用-P指定用哪个。比如mvn install -P pro，就会用生产环境的数据库连接。

还有版本号的问题。开发期间用SNAPSHOT快照版，每次变动都会推到仓库，别人拉代码时能自动更新。等项目稳定了就发RELEASE版，这个版本号不会再变。版本号通常写成1.2.3这样，1是大版本，2是功能更新，3是修bug，挺清楚的。

我用的Maven是3.8.4，装的时候下了官网的压缩包，解压后配环境变量。后来发现IDEA自带一个Maven，但版本不一样，还是用自己的比较踏实。仓库默认在国外，下载慢，我就在settings.xml里加了阿里云镜像，速度立马快了。

现在我写的每个项目都用Maven管理，虽然刚开始各种报错，但现在回头看，它确实把项目构建这件事标准化了。不用写ant脚本，不用手拷jar包，甚至连打包部署都能自动化。哪怕是个新手，照着步骤也能把项目跑起来。

说实话，Maven学起来不算轻松，光是pom.xml里的各种标签就得记一阵子。但一旦用顺了，开发效率是真的高。至少我现在不怕换电脑，只要装好环境，项目一拉下来，mvn clean install一遍，所有依赖自动下载，项目直接就能跑。