Maven 项目管理从未如此通畅
一，写在前面
Maven到底是什么？它能做些什么？能为我们的开发工作提供什么样的帮助？为什么会有如此大的知名度？另外，常听大厂的人说“私服”，工具管理吧啦吧啦的一堆也是不明觉厉。相信仁者见仁，着智者见智了。鄙人不才，整理了一下之前的笔记，与诸君分享，值当饭后茶点，欢迎指点。
二，场景模拟
情景一：日常开发中，比如做数据库操作，我需要引入诸如一下的jar包：
程序编译的时候，各种阴差阳错，会出现“ClassNotFoundException”，何解？唯有各种排查，也是比较闹心却也司空见惯了。
情景二：有过.net开发的人知道，比如，经常出现膈应的Newtonsoft.Json找不到的尴尬，此时只能从Nuget重新获取，或者从别处引用，那么会引起情景三。
情景三：现在的开发工作分模块，分功能，分业务，分流程等的开发模式，程序猿A在一处引入某jar包，程序猿B在另出引入该jar包，这样会造成代码的混乱和冗余。
情景四：我现在开发两个java项目A和B，其中项目A中的一些功能依赖于项目B中的某些类，也就是说项目A的运行，必须靠引入项目B打包后的jar文件才能执行。如果，项目B出现bug，那么A必须重新引入新的B的jar包。假设已经是线上项目，会不会显得被动了呢？！
总结，手动的添加删除jar包，而引发各种“血案”。
三，说说Maven
什么是架构？一个项目的整体架构的健全性，为项目的基本功能，规定了类和对象如何创建，如何协作，提供必要的支持性工作。
关于Maven，看看百度百科的说法
不过，我还是喜欢网上有位大神总结“Maven的核心功能就是合理叙述项目间的依赖关系”。通俗的说，就是通过pom.xml文件的配置获取jar包，而不再是手动添加jar包。其次，提供一个标准，配置文件不在杂乱无章，单元测试不再哪哪都是。
所有的Maven项目都包含着一个pom.xml，在这里记录着的<groupId><artifactId><version>等字段，这些字段在创建Maven项目时填写，后期也可以手动更改，Maven会依据它们来定位到该项目，进而完成jar的自动指引。
Maven主要做两件事：
统一管理jar包
统一开发规范于工具
四，说说pom.xml
pom.xml，这是Maven的核心配置文件，pom全称Project Object Model（项目对象模型），它描述的是整个Maven项目，或者说是Maven的描述文件：
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com</groupId> <artifactId>crm</artifactId> <version>1.0-SNAPSHOT</version> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>RELEASE</version> </dependency> </dependencies>
</project>
说说这几个关键词
1。groupId
公司或组织的名称。一般groupId由三部分组成“[项目用途].[公司名].[项目名]”，比如com.alibaba.taobao
2。artifactId
项目名
3。version
所需要jar的版本。SNAPSHOT意为快照，说明该项目在开发中。
以上三个元素，是Maven项目的基本坐标，非常厚重要。
4。packing
项目打包的类型，包括jar,war,rar,pom,ear，默认是jar
5。dependencies和dependency
简单的说，这里存放我们开发所需要的jar包。比如，上面的junit，表示我测试单元所引入的jar包。再如，Maven项目中提示找不到javax.sevlet.api，会通过在这里添加依赖：
<dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.1.0</version> <scope>provided</scope> </dependency>
6。properties
主要用来定义一些配置的属性，比如编码方式等
7。build
表示与构建相关的配置
<build> <plugins> <plugin> <groupId>org.mortbay.jetty</groupId> <artifactId>maven-jetty-plugin</artifactId> <version>6.1.7</version> <configuration> <connectors> <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector"> <port>8888</port> <maxIdleTime>30000</maxIdleTime> </connector> </connectors> <webAppSourceDirectory>${project.build.directory}/${pom.artifactId}-${pom.version} </webAppSourceDirectory> <contextPath>/</contextPath> </configuration> </plugin> </plugins> </build>
五，Maven的仓库
通过上面的pom.xml中配置，就能得到我开发中所需要的jar包，那么问题来了，这些jar在哪里，而我又怎么拿到呢？
这就引入了Maven仓库的概念。
Maven仓库分三种：本地仓库，第三方仓库（私服），中央仓库。
1.本地仓库
Maven项目创建后，在本地会有一个目录，在这里存放着几乎我所能用到的所有jar包，默认地址：$user.home/.m2/repository（我用mbp，cd usr/[电脑名]/.m2/ repository ）。我也可以修改默认地址，通过Maven目录下conf/setting.xml，修改localRepository字段就行。
2.第三方仓库
又称内部中心仓库，也叫私服。
一般由公司内部设立，只为本公司内部共享使用。它既可以作为公司内部构件协作和存档，也可以作为公用类库镜像缓存，减少外部访问和下载的频率。所以，对私服安全性问题要求非常的严格，需要单独配置，不然不能使用。
3.中央仓库
Maven内置了远程公用仓库，http://repo1.maven.org/maven2
这是由Maven团队维护，里面大约有1亿个常用类库，包括了市面大部分开源项目的构件，任你挑选。
总结，Maven项目获取jar包的过程
优先会从本地仓库查找jar包，如果没有，但是配置了私服，就会请求私服，从私服里获取jar，如果没有，就会从中央仓库里获取，直到找到对应jar包，然后下载到本地仓库，以便下次使用。如果没有私服，就直接去中央仓库获取。
先说这么多，后续再补。
