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 的生命周期:
一般情况下,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的一个镜像。
引言:
大家平时肯定都有用过全文检索工具,最常用的百度谷歌就是其中的典型。如果自己能够做一个那是不是想想就逼格满满呢。Apache就为我们提供了这样一个框架,
以下就是在实际开发中加入Lucene的一个小Demo。
这个项目是基于之前使用IDEA搭建的SSM的基础上进行增加的,
编写Lucene工具类
这个工具类中的具体代码我就不单独提出来说了,每个关键的地方我都写有注释,不清楚的再讨论。