产生背景
基于软件生命周期、项目自动化构建和jar包依赖管理而开发的工具
安装配置
Maven项目目录结构
src 是工作目录
main存放主程序代码
test存放测试代码
resources存放配置文件
java文件存放.java源文件
target 存放本项目打包后的jar包
pom.xml文件为本项目配置文件,仓库源,编译、测试、打包发布、安装
pom.xml文件结构
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.tl.g3</groupId>
<artifactId>berkeleyDB_weibo_search</artifactId>
<version>0.0.1-SNAPSHOT</version>
<!--仓库源可配置多个-->
<repositories>
<!--一个仓库源-->
<repository>
<id>xx</id><name>xx</name><url>xx</url>
</repository>
<repositories>
<!--依赖jar包可配置多个-->
<dependencies>
<!--一个依赖jar包-->
<dependency>
<groupId></g><a></a><v><v/><scope></scope>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
</plugins>
</build>
</project>
编译 --> 测试 --> 打包 --> 安装 --> 运行
scope的作用
1 compile,缺省值,适用于所有阶段,会随着项目一起发布。
2 provided,类似compile,期望JDK、容器或使用者会提供这个依赖。如servlet.jar。
3 runtime,只在运行时使用,如JDBC驱动,适用运行和测试阶段。
4 test,只在测试时使用,用于编译和运行测试代码。不会随项目发布。
5 system,类似provided,需要显式提供包含依赖的jar,Maven不会在Repository中查找它。
Maven仓库
Maven仓库主要分为2大类:本地仓库,远程仓库。
远程仓库主要分为3大类:私服,中央仓库,其他公共仓库。
通俗地讲,Maven仓库主要是用于存储jar包的。
我们在pom.xml文件中的添加的依赖<dependency>中的gav坐标告诉Maven找哪个jar包,但是去哪找,就是Maven仓库来负责了,Maven仓库的搜索优先级如下:
搜索本地仓库(具体存储路径有什么特点我们上面也讲了),如果没有,则
搜索远程仓库。
如果我们配置了私服(企业搭建,给企业内部开发人员使用,或者配置为云服务开放给更多人使用),那么在搜索远程仓库时:
搜索私服,如果没有,则
搜索中央仓库,如果没有,则(根据配置)
搜索其他公共仓库。
上面我们已经讲了本地仓库如何配置了,下面我们讲远程仓库中私服的配置。
将下面文字添加到项目的pom.xml文件中,与<dependencies></dependencies>同一个级别。
<!-- 首先配置仓库的服务器位置,首选阿里云,也可以配置镜像方式,效果雷同 -->
<repositories>
<repository>
<id>nexus-aliyun</id>
<name>Nexus aliyun</name>
<url>http://maven.aliyun.com/nexus/content/groups/public</url>
</repository>
</repositories>
如下图
上面的repository标签配置的就是一个私服(阿里搭建的,但是开放给了公众)。如果不配置,我们本地仓库如果没有jar包,就会直接搜索中央仓库。
Maven命令
mvn clean
mvn clean compile
mvn clean test
mvn clean package
mvn clean install
建议大家养成一个习惯,在每个操作前先clean ,只执行mvn clean会删除target目录。
Maven命令执行时有个特点,它会把之前的过程先执行完毕。比如:
虽然我们只运行了mvn clean test,但它实际上是先执行了mvn clean compile,再执行test;
虽然我们只运行了mvn clean package,但它实际上是先执行了mvn clean compile,再执行test,再执行package。
依此类推。
这里涉及到了Maven生命周期,大家可以参考最后的推荐书目。那本书有详细的解释。
打包给普通项目使用
普通项目要在项目依赖的包文件下导入jar包,并右键项目build path add jar
打包给本地Maven项目使用
直接将被使用的jar包安装到本地仓库 运行mvn install,然后在需要使用时修改pom.xml文件加入依赖的jai包 gav即可
打包给远程Maven项目使用
需要被使用的jar包部署到远程仓库,需要在配置文件中添加配置。
打包成独立程序可直接运行
要修改pom.xml,添加专门的打包插件(maven-assembly-plugin),另外还有一款可以解决jar包冲突的打包插件(maven-shade-plugin)。这里只说解第一款。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<version>2.3</version>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
<archive>
<manifest>
<mainClass>入口类的全名</mainClass>
</manifest>
</archive>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>assembly</goal>
</goals>
</execution>
</executions>
</plugin>
之后,只需要运行一条命令即可:mvn clean package。去target目录下:
把这个jar包复制到其他地方,比如放到桌面,可以重命名:
然后在CMD中运行 java -jar test.jar即可。