2)变量配置信息
pom.xml 文件的第二部分通常用来配置一些变量信息。
<properties> <spring.version>5.1.5.RELEASE</spring.version> </properties>
有了变量的配置信息后,可以通过 ${spring.version}
的形式来调用这些配置项。这样做的好处显而易见,当依赖项的版本升级的时候,可以直接修改变量值即可。
3)依赖管理
阿里云的 Maven 仓库下有各种各样的第三方类库,换句话说就是,只有你想不到的,没有你找不到的。大多数 Maven 项目的依赖项列表都会很长很长,为了便于说明,下面我只列出某些具有特色的。
<dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>3.8.1</version> <scope>test</scope> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> <exclusions> <exclusion> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version>1.1.1</version> </dependency> </dependencies>
①、上文中曾提到,<groupId>
、<artifactId>
、<version>
合起来可以准确地定位一个依赖项。那怎么找到想要的依赖项呢?
第一步,进入 MavenRepository 网站,地址如下:
然后在搜索框中输入第三方类库的关键字,比如说「spring-core」,点击「search」按钮,可以查看到该类库的链接导航。
第二步,点击链接进入到「spring-core」的主页,可以看到所有版本的「spring-core」,选择一个使用率最高的。使用率高在一定程度上表明这个版本的类库最稳定,它已经得到了广大程序员的认可。
第三步,进入该版本的主页,只需要左键轻轻地在 「Maven」选项卡内点一下,就已经把该类库的 Maven 依赖信息复制到粘贴板了(不需要「Ctrl+C」,非常的人性化),如下图所示。
第四步,将类库的依赖信息粘贴到 pom.xml 文件的 <dependencies>
节点下,然后按下快捷键「Ctrl+S」保存。紧接着,依次展开 test → Java Resources → Libraries → Maven Dependencies 节点,你可以看到该类库已经悄悄地添加进来了。
②、 <exclusions>
主要用于排除依赖。
有时候,我们引入的依赖中可能会包含一些不想要的依赖包,我们想引入自己想要的,这时候就要用到排除依赖了。
使用 <exclusion>
的时候只需要指定 groupId 和 artifactId 就行了,并不需要 version,这是因为 groupId 和 artifactId 就可以定位某种类型的依赖。
③、 <scope>
用来控制依赖的范围。
test:测试依赖范围。典型的例子是 Jnuit,它只有在编译测试代码及运行测试的时候才需要。
compile:编译依赖范围(其实不止是编译,对测试、运行同样有效),缺省项,如果没有指定,就会默认使用该依赖范围。
provided:提供依赖范围。对编译和测试有效,但在运行时候无效。
runtime:运行时依赖范围。对测试和运行有效,但在编译时无效。
PS:如果不知道选哪一种,缺省就对了。
4)构建配置
<build>
元素中包含了执行 Maven 构建周期目标所需的插件以及相关的配置。
<build> <finalName>test</finalName> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.3.2</version> <configuration> <source>${jdk.version}</source> <target>${jdk.version}</target> </configuration> </plugin> </plugins> <resources> <resource> <directory>src/main/java</directory> <includes> <include>**/*.xml</include> </includes> </resource> </resources> </build>
①、<finalName>
,打成 jar 包或者 war 包时的名称。上文中曾提到,项目打包后的输出目录为 ${basedir}/target
。
②、<plugins>
用于指定项目在构建过程中使用的插件。
<groupId>
、<artifactId>
、<version>
用于确定使用的插件。configuration
,该插件所需要的特殊配置。Maven 3 默认使用的是 JDK 1.5,本例中我们使用了 JDK 1.8。
③、<resources>
描述了各个资源在 Maven 项目中的具体路径。
<directory>
,资源文件的路径,默认位于${basedir}/src/main/resources/
目录下。includes
,用于指定在构建过程中被处理的资源文件;对应excludes
用于省去不被处理的资源文件。
05、使用 Maven 对项目进行清理、编译、测试、打包
1)清理:mvn clean
,该命令会删除 target 目录。可以直接在命令行中执行该命令,只需要切换到项目所在的路径下即可。
2)编译:mvn complie
,该命令会编译 src/main/java 目录下的源码。同时,Maven 还会处理在 src/main/resources 目录下的资源文件,确保它们作为编译的一部分。
不过,很遗憾的是,执行该命令会报错。该命令给出的提示是,查看 [Help 1] 给出的地址,我尝试了一下,可以将 mvn complie
命令替换为 mvn compiler:compile
命令执行,结果如下图所示。
编译后可以在 target 目录下查看字节码文件。
3)测试:mvn test
,test 命令在运行时,会执行 compile 命令;而之前我们已经执行过一次 compile 命令,为了确保结果的准确性,可以执行 mvn clean test
命令确保测试之前没有残余物,结果如下图所示。
Maven 会通过 Surefire 插件,使用 pom.xml 文件中的测试提供者(通常是 Junit)运行测试。执行 test
命令不仅会运行测试,还会产生报告文件,此时 target 目录下的截图如下:
4)打包:mvn install
,该命令会按照 pom.xml 文件中 <packaging>
指定的方式(本例为 jar)对编译结果打包。同时,还会把打包好的文件放到本地的 Maven 仓库中,以便其他项目把它当做依赖项使用。命令执行结果如下图所示。
查看本地的 Maven 仓库,可以看到刚刚打包好的文件。
06、最后
在 Maven 出现之前,流行的构建工具是 Ant;在 Maven 出现之后,还有一种新兴的构建工具 Gradle,它有意选择了和 Maven 相反的原则,不会强制使用者遵循刻板的构建周期。
总之,Maven 是一款优秀的构建工具,Java 项目的开发者很有必要熟练地掌握它。