本篇内容主要讲解“Maven的插件以及生命周期的介绍”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Maven的插件以及生命周期的介绍”吧!
Maven：是一个项目管理和整合工具(类似python中的pi 不过更加强大而已)。Maven 为开发者提供了一套完整的构建生命周期框架。开发团队几乎不用花多少时间就能够自动完成工程的基础构建配置，因为 Maven 使用了一个标准的目录结构和一个默认的构建生命周期。这里切记 约定大于配置。简而言之：
Maven 的主要目的是为开发者提供
一个可复用、可维护、更易理解的工程综合模型
与这个模型交互的插件或者工具
Maven的仓库管理、依赖管理、继承和聚合等特性为项目的构建提供了一整套完善的解决方案
maven的构建生命周期，只是一个抽象规范流程。周期内的每个阶段的具体执行，是在插件里来实现。
运行任何一个阶段，都会从其所在生命周期的第一个阶段开始，顺序执行到指定的阶段
插件plugin是绑定到生命周期，承担实际功能的组件。mvn运行时，自动关联插件来运行。可以简单的理解为一个插件就是一个package，里面有细节的.class文件，.class文件里又有具体的操作函数。
上面描述了我们对Maven的一些使用方式，下面我们进行一些思考：
Maven仓库：
本地仓库路径配置：
你要jar包，不可能每次都要联网去下载吧，多费劲，所以本地仓库就是相当于加了一层jar包缓存，先到这里来查。如果这里查不到，那么就去私服上找，如果私服也找不到，那么去中央仓库去找，找到jar后，会把jar的信息同步到私服和本地仓库中。
私服，就是公司内部局域网的一台服务器而已，你想一下，当你的工程Project-A依赖别人的Project-B的接口，怎么做呢？没有Maven的时候，当然是copy Project-B jar到你的本地lib中引入，那么Maven的方式，很显然需要其他人把Project-B deploy到私服仓库中供你使用。因此私服中存储了本公司的内部专用的jar！不仅如此，私服还充当了中央仓库的镜像，说白了就是一个代理！
中央仓库：该仓库存储了互联网上的jar，由Maven团队来维护，地址是：http://repo1.maven.org/maven2/。
依赖管理：
其实这个标签揭示了jar的查找坐标：groupId、artifactId、version。
一般而言，我们可以到私服上输入artifactId进行搜索，或者到http://search.maven.org/、http://mvnrepository.com/上进行查找确定坐标。
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版本！
依赖的版本？
首先来说，对于Maven而言，同一个groupId同一个artifactId下，只能使用一个version！
根据上图的依赖顺序，将使用1.2版本的jar。
现在，我们可以思考下了，比如工程中需要引入A、B，而A依赖1.0版本的C，B依赖2.0版本的C，那么问题来了，C使用的版本将由引入A、B的顺序而定？这显然不靠谱！如果A的依赖写在B的依赖后面，将意味着最后引入的是1.0版本的C，很可能在运行阶段出现类（ClassNotFoundException）、方法（NoSuchMethodError）找不到的错误（因为B使用的是高版本的C）！
这里其实涉及到了2个概念：依赖传递（transitive）、Maven的最近依赖策略。
依赖传递：如果A依赖B，B依赖C，那么引入A，意味着B和C都会被引入。
Maven的最近依赖策略：如果一个项目依赖相同的groupId、artifactId的多个版本，那么在依赖树（mvn dependency:tree）中离项目最近的那个版本将会被使用。（从这里可以看出Maven是不是有点小问题呢？能不能选择高版本的进行依赖么？据了解，Gradle就是version+策略）
现在，我们可以想想如何处理依赖冲突呢？
想法1：要使用哪个版本，我们是清楚的，那么能不能不管如何依赖传递，都可以进行版本锁定呢？
想法2：在依赖传递中，能不能去掉我们不想依赖的？
想法3：既然是最近依赖策略，那么我们就直接使用显式依赖指定版本，那不就是最靠近项目的么？
在工程中，我们避免不了需要加一些依赖，也许加了依赖后运行时才发现存在依赖冲突在去解决，似乎有点晚！那么能不能提前发现问题呢？
如果我们新加入一个依赖的话，那么先通过mvn dependency:tree命令形成依赖树，看看我们新加入的依赖，是否存在传递依赖，传递依赖中是否和依赖树中的版本存在冲突，如果存在多个版本冲突，利用上文的方式进行解决！
src/main/java –存放项目的.java文件 |
src/main/resources –存放项目资源文件。比方spring,hibernate配置文件 |
src/test/java –存放全部測试.java文件，比方JUnit測试类 |
src/test/resources 一測试资源文件 |
target 一项目输出位置,编译完毕后的东西放到这里面 |
pom.xml 一整个项目的构建计划书 |
这里需要注意2点：
第一：src/main下内容最终会打包到Jar/War中，而src/test下是测试内容，并不会打包进去。
第二：src/main/resources中的资源文件会COPY至目标目录，这是Maven的默认生命周期中的一个规定动作。（想一想，hibernate/mybatis的映射XML需要放入resources下，而不能在放在其他地方了）
Maven生命周期：
我们只需要注意一点：执行后面的命令时，前面的命令自动得到执行。
实际上，我们最常用的就是这么几个：
clean： 有问题，多清理！
package：打成Jar or War包，会自动进行clean+compile
install： 将本地工程Jar上传到本地仓库
deploy： 上传到私服
既然，Maven的生命周期存在编译、测试、运行这些过程，那么显然有些依赖只用于测试，比如junit；有些依赖编译用不到，只有运行的时候才能用到，比如mysql的驱动包在编译期就用不到（编译期用的是JDBC接口），而是在运行时用到的；还有些依赖，编译期要用到，而运行期不需要提供，因为有些容器已经提供了，比如servlet-api在tomcat中已经提供了，我们只需要的是编译期提供而已。
总结来说：
compile：默认的scope，运行期有效，需要打入包中。
provided：编译期有效，运行期不需要提供，不会打入包中。servlet-api
runtime：编译不需要，在运行期有效，需要导入包中。（接口与实现分离）jdbc
test：测试需要，不会打入包中。junit
system：非本地仓库引入、存在系统的某个路径下的jar。（一般不使用）
到此，相信大家对“Maven的插件以及生命周期的介绍”有了更深的了解，不妨来实际操作一番吧！这里是亿速云网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
