jar文件包括java普通类、资源文件和普通文件，在maven中即是打包src/main/java和src/main/resources资源文件夹下的所有文件。在打包的时候会自动生成MATA-INF文件夹，用于存储maven的pom信息和MANIFEST.MF文件。
war文件包含全部的web应用程序，即所有的java类，配置信息和jsp、js等静态资源。但是需要注意war引用war的时候会将应用war的资源全部拷贝到当前war的相同文件下，重名的文件会被替换。例如:
war包依赖：
1 <dependency>
2 <groupId>com.my.module</groupId>
3 <artifactId>module1</artifactId>
4 <version>0.0.1-SNAPSHOT</version>
5 <type>war</type> //根据这个来看打什么包
6 </dependency>
打成包的位置 ，这是我直接 项目右键->run as->maven clean 完了后 maven install
Maven 仓库：
在Maven中，任何一个依赖、插件或者项目构建的输出，都可以称之为构件。
Maven在某个统一的位置存储所有项目的共享的构件，这个统一的位置，我们就称之为仓库。（仓库就是存放依赖和插件的地方）
中央仓库：我理解的就是官方的依赖包等下载 私服：是公司自己配的 其他仓库：就是阿里的吧。。。。。。
任何的构件都有唯一的坐标，Maven根据这个坐标定义了构件在仓库中的唯一存储路径，
Maven 仓库的分类：（比较正经的解释）
本地仓库，Maven核心自带的远程仓库，包括了绝大数开源的构件。默认如果本地仓库没有的时候从中央仓库下载。
注：maven的本地仓库，在安装maven后并不会创建，它是在第一次执行maven命令的时候才被创建
maven本地仓库的默认位置：无论是Windows还是Linux，在用户的目录下都有一个.m2/repository/的仓库目录，这就是Maven仓库的默认位置
如何更改maven默认的本地仓库的位置：这里要引入一个新的元素：localRepository，它是存在于maven的settings.xml文件中在conf目录下
更改配置用户范围的本地仓库：先在/.m2/目录下创建settings.xml文件，然后在~/.m2/settings.xml，设置localRepository元素的值为想要的仓库地址
- <settings>
- <localRepository>D:\maven_new_repository</localRepository>
- </settings>
这时候，maven的本地仓库地址就变成了 D:\maven_new_repository ，注：此时配置的maven的本地仓库是属于用户范围的。
1.2 更改配置全局范围的本地仓库：在M2_HOME/conf/settings.xml中更改配置，更改配置的方法同上
注：此时更改后，所有的用户都会受到影响，而且如果maven进行升级，那么所有的配置都会被清除，所以要提前复制和备份M2_HOME/conf/settings.xml文件
故：一般情况下不推荐配置全局的settings.xml
远程仓库
安装好Maven后，如果不执行任何Maven命令，本地仓库的目录是不存在的。当用户输入第一条Maven命令之后，Maven才会创建本地仓库，然后根据配置和需要，从远程仓库下载构件至本地仓库。
由于原始的本地仓库是空的，Maven必须知道至少一个可用的远程仓库，才能在执行Maven命令的时候下载需要的构件。重要仓库是默认的远程仓库，Maven的安装目录自带了中央仓库的配置。在$M2_HOME/lib/maven-model-builder-3.0.jar的org/apache/maven/model/pom-4.0.0.xml。存在如下配置：
这个文件是所有Maven项目都会继承的超级POM。之后详细介绍继承和超级POM。
尤其是注意Maven自带中央仓库的id是central，如果其他仓库声明也使用该id，就会覆盖中央仓库配置
使用id central对中央仓库进行唯一表示。
name url 使用默认的仓库布局。snapshots元素子元素enabled的值为false，表示不会 从该中央仓库下载快照版本的构件。 enable：是否开启release或者snapshots的下载支持。
updatePolicy：用来配置Maven从远程仓库检查更新的频率，默认是daily，表示每天检查一次；never：从不检查更新；always：每次构建都检查更新；interval：X 每隔X分钟检查一次更新。
值是warn，会执行构建时输出警告信息，其他可用——fail：遇到校验和错误就构件失败；
ignore：完全忽略校验和错误。
远程仓库的认证
大部分无需验证就可直接访问，但是出于安全可以配置仓库用户名和密码，所以需要认证。
配置认证信息和配置仓库信息不同，仓库信息可以直接配置在POM文件中，但是认证信息必须配置在settings.xml文件中。这是因为POM往往被提交代码仓库供所有成员访问，而settings.xml一般只放在本机，所以更安全。
id：必须和POM中需要认证的Repository元素的id完全一致。正是这个id将认证信息和仓库配置联系在一起。
username：
password：
私服：（常用私服软件：Nexus）
私服代理广域网上的远程仓库，供局域网内的Maven用户使用。当Maven需要下载构件的时候，它从私服请求，如果私服上不存在该构件，则从外部的远程仓库下载，缓存在私服之后，再为Maven的下载请求提供服务，此外，一些无法从外部仓库下载到的构件也可能从本地上传到私服上供大家使用。
使用私服的优点：.节省自己的外网带宽 .加速Maven构件 .部署第三方构件 .提高稳定性。增强控制 .降低中央仓库的负荷
Maven 的生命周期：
一般情况下，mvn clean install 这样的命令是通用的。我想，一定是吸收了许多项目的经验，Maven才能定义出如此完善的模型。
maven有三套生命周期 相互独立，我也一直恩我maven是一个整体的生命周期，那一起来学习吧。
Clean 在进行真正的构建之前进行一些清理工作。
Default 构建的核心部分，编译，测试，打包，部署等等。
Site 生成项目报告，站点，发布站点
也可以用 mvn clean install site 运行所有这三套生命周期。
mvn clean（2 清理上一次构建生成的文件） 等同于 mvn pre-clean （1，清理前期需要完成的工作） ，如果我们运行 mvn post-clean（3，执行一些清理后的工作），那么 pre-clean，clean 都会被运行。这是Maven很重要的一个规则，可以大大简化命令行的输入。1 2 3 是三个阶段
来看一下Maven的最重要的Default生命周期，绝大部分工作都发生在这个生命周期中，这里，我只解释一些比较重要和常用的阶段：这是从一本书上看的 我就抄过来了---《Maven 实战》
- validate
- generate-sources
- process-sources
- generate-resources
- process-resources 复制并处理资源文件，至目标目录，准备打包。
- compile 编译项目的源代码。
- process-classes
- generate-test-sources
- process-test-sources
- generate-test-resources
- process-test-resources 复制并处理资源文件，至目标测试目录。
- test-compile 编译测试源代码。
- process-test-classes
- test 使用合适的单元测试框架运行测试。这些测试代码不会被打包或部署。
- prepare-package
- package 接受编译好的代码，打包成可发布的格式，如 JAR 。
- pre-integration-test
- integration-test
- post-integration-test
- verify
- install 将包安装至本地仓库，以让其它项目依赖。
- deploy 将最终的包复制到远程的仓库，以让其它开发人员与项目共享。
下面看一下Site生命周期的各个阶段：
- pre-site 执行一些需要在生成站点文档之前完成的工作
- site 生成项目的站点文档
- post-site 执行一些需要在生成站点文档之后完成的工作，并且为部署做准备
- site-deploy 将生成的站点文档部署到特定的服务器上
总结：它前面的所有阶段都会被运行，这也就是为什么我们运行mvn install 的时候，代码会被编译，测试，打包
Maven的插件
Maven的核心文件很小，主要的任务都是由插件来完成。定位到：%本地仓库%\org\apache\maven\plugins，可以看到一些下载好的插件：plugins包下：以提供特定的功能.可以说是一种插件
插件的目标（Plugin Goals）
一个插件通常可以完成多个任务，每一个任务就叫做插件的一个目标。如执行mvn install命令时，调用的插件和执行的插件目标如下：
将插件绑定到生命周期
Maven的生命周期是抽象的，实际需要插件来完成任务，这一过程是通过将插件的目标（goal）绑定到生命周期的具体阶段（phase）来完成的。如：将maven-compiler-plugin插件的compile目标绑定到default生命周期的compile阶段，完成项目的源代码编译：
内置的绑定
Maven对一些生命周期的阶段（phase）默认绑定了插件目标，因为不同的项目有jar、war、pom等不同的打包方式，因此对应的有不同的绑定关系，其中针对default生命周期的jar包打包方式的绑定关系如下：
第二列中，冒号后面即是绑定的插件目标，冒号前面是插件的前缀（prefix），是配置和使用插件的一种简化方式。
自定义绑定
用户可以根据需要将任何插件目标绑定到任何生命周期的阶段，如：将maven-source-plugin的jar-no-fork目标绑定到default生命周期的package阶段，这样，以后在执行mvn package命令打包项目时，在package阶段之后会执行源代码打包，生成如：ehcache-core-2.5.0-sources.jar形式的源码包。
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-source-plugin</artifactId>
<version>2.2.1</version>
<executions>
<execution>
<id>attach-source</id>
<phase>package</phase><!-- 要绑定到的生命周期的阶段 -->
<goals>
<goal>jar-no-fork</goal><!-- 要绑定的插件的目标 -->
</goals>
</execution>
</executions>
</plugin>
</plugins>
……
</build>
配置插件
Maven插件高度易扩展，可以方便的进行自定义配置。如：配置maven-compiler-plugin插件编译源代码的JDK版本为1.7：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.7</source>
<target>1.7</target>
</configuration>
</plugin>
也可以对插件的各个目标进行更具体的配置。
插件仓库
跟其他构件一样，插件也是根据坐标存储在Maven仓库中。超级POM中Maven配置的默认插件远程仓库如下：
<pluginRepositories>
<pluginRepository>
<id>central</id>
<name>Central Repository</name>
<url>http://repo.maven.apache.org/maven2</url>
<layout>default</layout>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<updatePolicy>never</updatePolicy>
</releases>
</pluginRepository>
</pluginRepositories>
镜像：
如果仓库X可以提供仓库Y存储的所有内容，那么就可以说X是Y的一个镜像。
配置在settings.xml中。
例子：
<mirrorOf>标签的值是central，表示该配置为中央仓库的镜像，任何对于中央仓库的请求都会转至该镜像。
id,name,url 和一般仓库配置无异。
<mirrorOf>* </mirrorOf>：所有仓库的镜像，任何对于远程仓库的请求都会转至镜像。
今天先到这里 其实我都看懵了慢慢消化。哈哈哈哈！！！！！
引言：
大家平时肯定都有用过全文检索工具，最常用的百度谷歌就是其中的典型。如果自己能够做一个那是不是想想就逼格满满呢。Apache就为我们提供了这样一个框架，
以下就是在实际开发中加入Lucene的一个小Demo。
这个项目是基于之前使用IDEA搭建的SSM的基础上进行增加的，
编写Lucene工具类
这个工具类中的具体代码我就不单独提出来说了，每个关键的地方我都写有注释，不清楚的再讨论。
