Maven Helper的使用
Maven中Scope参考文章
jar包和Maven之间的依赖关系
我们知道,maven的依赖关系是有传递性的。如:A–>B,B–>C。但有时候,项目A可能不是必需依赖C,因此需要在项目A中排除对A的依赖。在maven的依赖管理中,有两种方式可以对依赖关系进行,分别是可选依赖(Optional Dependencies)以及依赖排除(Dependency Exclusions)。
一、可选依赖
当一个项目A依赖另一个项目B时,项目A可能很少一部分功能用到了项目B,此时就可以在A中配置对B的可选依赖。举例来说,一个类似hibernate的项目,它支持对mysql、oracle等各种数据库的支持,但是在引用这个项目时,我们可能只用到其对mysql的支持,此时就可以在这个项目中配置可选依赖。
配置可选依赖的原因:1、节约磁盘、内存等空间;2、避免license许可问题;3、避免类路径问题,等等。
示例:
<project>
...
<dependencies>
<!-- declare the dependency to be set as optional -->
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional> <!-- value will be true or false only -->
</dependency>
</dependencies>
</project>
假设以上配置是项目A的配置,即:Project-A --> Project-B。在编译项目A时,是可以正常通过的。
如果有一个新的项目X依赖A,即:Project-X -> Project-A。此时项目X就不会依赖项目B了。如果项目X用到了涉及项目B的功能,那么就需要在pom.xml中重新配置对项目B的依赖。
二、依赖排除
当一个项目A依赖项目B,而项目B同时依赖项目C,如果项目A中因为各种原因不想引用项目C,在配置项目B的依赖时,可以排除对C的依赖。
示例(假设配置的是A的pom.xml,依赖关系为:A --> B; B --> C):
<project>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion> <!-- declare the exclusion here -->
<groupId>sample.ProjectC</groupId>
<artifactId>Project-C</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>
当然,对于多重依赖,配置也很简单,参考如下示例:
```java
Project-A
-> Project-B
-> Project-D
-> Project-E <! -- This dependency should be excluded -->
-> Project-F
-> Project C
A对于E相当于有多重依赖,我们在排除对E的依赖时,只需要在配置B的依赖中进行即可:
```java
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
...
<dependencies>
<dependency>
<groupId>sample.ProjectB</groupId>
<artifactId>Project-B</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>sample.ProjectE</groupId> <!-- Exclude Project-E from Project-B -->
<artifactId>Project-E</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
</project>
1.json-lib
<dependency>
<groupId>net.sf.json-lib</groupId>
<artifactId>json-lib</artifactId>
<version>2.4</version>
<classifier>jdk15</classifier>
</dependency>
在maven官网中的提示添加的配置信息,没有标签,此处一定要加上,不然会报错:missing net.sf.json-lib:json-lib:2.4.
而且试了16/17/18后均提示同样的错误,只有写15才可以,原因不明。
pom版本依赖
场景1
场景: 有两个web项目A、B,一个java项目C,它们都需要用到同一个jar包:common.jar
问题: 如果分别在三个项目的pom文件中定义各自对common.jar的依赖,那么当common.jar的版本发生变化时,三个项目的pom文件都要改,项目越多要改的地方就越多,很麻烦。
解决: 这时候就需要用到parent标签, 我们创建一个parent项目,打包类型为pom
,parent项目中不存放任何代码,只是管理多个项目之间公共的依赖。在parent项目的pom文件中定义对common.jar的依赖,ABC三个子项目中只需要定义,parent标签中写上parent项目的pom坐标就可以引用到common.jar了。
场景2
场景: 有一个springmvc.jar,只有AB两个web项目需要,C项目是java项目不需要,那么又要怎么去依赖。
问题: 如果AB中分别定义对springmvc.jar的依赖,当springmvc.jar版本变化时修改起来又会很麻烦。
解决: 是在parent项目的pom文件中使用<dependencyManagement></dependencyManagement>
将springmvc.jar管理起来,如果有哪个子项目要用,那么子项目在自己的pom文件中使用
<dependency>
<groupId></groupId>
<artifactId></artifactId>
</dependency>
标签中写上springmvc.jar的坐标,不需要写版本号,可以依赖到这个jar包了。这样springmvc.jar的版本发生变化时只需要修改parent中的版本就可以了。
所有模块都需要使用的包
SNAPSHOT的jar包更新机制:
releases:线上版本(生产环境使用的)
snapshots:快照版本(开发过程中使用的):
参考文章,点击这里
区别:
如果是快照版本,那么在mvn deploy时会自动发布到快照版本库中,而使用快照版本的模块,在不更改版本号的情况下,直接编译打包时,maven会自动从镜像服务器上下载最新的快照版本。如果是正式发布版本,那么在mvn deploy时会自动发布到正式版本库中,而使用正式版本的模块,在不更改版本号的情况下,编译打包时如果本地已经存在该版本的模块则不会主动去镜像服务器上下载。
pom文件的配置
<build>
<finalName>ff-model</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.1</version>
<configuration>
<source>1.7</source>
<target>1.7</target>
<encoding>UTF-8</encoding>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.17</version>
<configuration>
<skipTests>true</skipTests>
</configuration>
</plugin>
<plugin>
<artifactId>maven-source-plugin</artifactId>
<executions>
<execution>
<id>attach-sources</id>
<phase>deploy</phase>
<goals>
<goal>jar-no-fork</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-javadoc-plugin</artifactId>
<executions>
<execution>
<id>attach-javadocs</id>
<phase>deploy</phase>
<goals>
<goal>jar</goal>
</goals>
</execution>
</executions>
</plugin>
<plugin>
<!-- explicitly define maven-deploy-plugin after other to force exec
order -->
<artifactId>maven-deploy-plugin</artifactId>
<executions>
<execution>
<id>deploy</id>
<phase>deploy</phase>
<goals>
<goal>deploy</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
<resources>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.dic</include>
<include>**/*.xml</include>
</includes>
</resource>
<resource>
<directory>src/main/resources</directory>
</resource>
</resources>
</build>
<distributionManagement>
<repository>
<id>releases</id>
<url>http://nexus.xx.com/content/repositories/releases</url>
</repository>
<snapshotRepository>
<id>snapshots</id>
<url>http://nexus.xx.com/content/repositories/snapshots</url>
</snapshotRepository>
</distributionManagement>
settings文件的配置:
<server>
<id>releases</id>
<username>admin</username>
<password>admin123</password>
</server>
<server>
<id>snapshots</id>
<username>admin</username>
<password>admin123</password>
</server>
注意pom.xml中的id和setting.xm的id名称要一致
5.Maven相关命令
参考文档
代码编写完后,可以使用下面命令进行编译:
mvn clean compile
首先执行clean任务,删除target目录。接着执行resources任务,最后执行compile目录,将项目主代码编译到target/classes目录。
调用Maven执行测试:
mvn clean test
打包,Maven打包执行会执行编译,测试等操作,将项目打成jar包或者war包,存放在target/目录下,默认包名为artifact-version.jar
mvn clean package
若想修改打包后的包名,在build元素下添加:
<build>
<finalName>${project.artifactId}-${project.version}-xxx</finalName>
</build>
打包并上传到Maven本地仓库,这样其他maven项目就能使用它了。
mvn clean install
将项目打成jar包并部署到私服(远程仓库)
mvn clean deploy
打包、上传、部署时忽略test文件使用命令
mvn clean xxx -Dmaven.test.skip=true