这是我参与更文挑战的第5天，活动详情查看： 更文挑战
背景
使用Maven创建项目时,会默认生成如下几个文件,这几个文件是做什么用的呢?
├── .mvn
│ └── wrapper
│ ├── maven-wrapper.jar
│ └── maven-wrapper.properties
├── mvnw
└── mvnw.cmd
maven-wrapper
传统使用maven的方式
- 先到官网上下载maven,然后配置环境变量把mvn可执行文件路径加入到环境变量，以便之后使用直接使用mvn命令。
- 另外项目pom.xml文件描述的依赖文件默认是下载在用户目录下的.m2文件下的repository目录下。
- 如果需要更换maven的版本，需要重新下载maven并替换环境变量path中的maven路径。
maven-wrapper的目的
maven-wrapper的出现就是为了在更换maven版本时不用手动去做上面的操作:
- 执行mvnw比如mvnw clean，如果本地没有匹配的maven版本，直接会去下载maven，放在用户目录下的.m2/wrapper中
- 并且项目的依赖的jar包会直接放在项目目录下的repository目录，这样可以很清晰看到当前项目的依赖文件。
- 如果需要更换maven的版本，只需要更改项目当前目录下.mvn/wrapper/maven-wrapper.properties的distributionUrl属性值，更换对应版本的maven下载地址。mvnw命令就会自动重新下载maven。
可以说带有mvnw文件的项目，除了额外需要配置java环境外，只需要使用本项目的mvnw脚本就可以完成编译，打包，发布等一系列操作。
个人理解
- maven wrapper可以自动下载maven，但实际上我们常用的idea软件都自带了maven。
- 如果用上了ide，一般习惯也是直接使用Navigation Bar执行maven命令比较方便。
- maven wrapper根据配置自动切换maven版本。这个看起来很有用，但实际上maven版本也是很稳定。很少会出现需要切换maven版本的情况
- 使用mvnw命令会在直接当前项目下生成repository，看起来每一个项目独立了repository，很模块化的样子。但是这样不仅浪费了磁盘空间，且实际上开发中并不关心repository，idea会自动有external librayies目录提供查看依赖的jar包。
maven-wrapper解决了2个问题
- 可以为某个Java工程指定某个特定Maven版本，避免因为版本差异引起的诡异错误，这样就统一该项目的开发环境
- 不再需要提前安装Maven，简化了开发环境的配置
