下面是三要素,必须有













groupId: 定义当前Maven项目隶属的实际项目(三要素必须有,没有就报错)
artifactId: 该元素定义实际项目中的一个Maven项目或模块(三要素必须有,没有就报错)
version: 该元素定义Maven项目当前所处的版本(三要素必须有,没有就报错)

scope: compile默认,不配置就是这个compile表示被依赖项目需要参与当前项目的编译，当然后续的测试，运行周期也参与其中，是一个比较强的依赖。打包的时候通常需要包含进去。

testscope为test表示依赖项目仅仅参与测试相关的工作，包括测试代码的编译，执行。比较典型的如 junit。

provided意味着打包的时候可以不用包进去，别的设施(Web Container)会提供。事实上 该依赖理论上可以参与编译，测试，运行等周期。相当于compile，但是在打包阶段做了exclude的动作。(javax.servlet-api和jsp-api都需要这个scope属性)

packaging: 该元素定义Maven项目的打包方式
classifier: 该元素用来帮助定义构建输出的一些附属构件

关于使用

依赖管理：

其实这个标签揭示了jar的查找坐标：groupId、artifactId、version。

一般而言，我们可以到私服上输入artifactId进行搜索，或者到http://search.maven.org/、http://mvnrepository.com/上进行查找确定坐标。

version分为开发版本（Snapshot）和发布版本（Release)

version分为开发版本（Snapshot）和发布版本（Release），那么为什么要分呢？

在实际开发中，我们经常遇到这样的场景，比如A服务依赖于B服务，A和B同时开发，B在开发中发现了BUG，修改后，将版本由1.0升级为2.0，那么A必须也跟着在POM.XML中进行版本升级。过了几天后，B又发现了问题，进行修改后升级版本发布，然后通知A进行升级…可以说这是开发过程中的版本不稳定导致了这样的问题。

Maven，已经替我们想好了解决方案，就是使用Snapshot版本，在开发过程中B发布的版本标志为Snapshot版本，A进行依赖的时候选择Snapshot版本，那么每次B发布的话，会在私服仓库中，形成带有时间戳的Snapshot版本，而A构建的时候会自动下载B最新时间戳的Snapshot版本！