Maven的pom文件那些事

pom.xml文件

<groupId>org.son.nexus</groupId>//项目隶属的实际项目名
<artifactId>nexus-indexer</artifactId>//实际项目中的一个maven项目模块名称
<version>2.0.0</version>//版本号
<packaging>jar</packaging>//当前maven项目打包的方式,默认为jar

以上的配置会获得一个-.格式的包//nexus-indexer-2.0.0.jar

jdk7//用于定义构建输出的一些附属的构建。classifier是不能直接定义的,只能存在附加的构件(插件)时,才能(必须)添加。在包名上也会有所提现(nexus-indexer-2.0.0-javadoc.jar)

jar包在仓库中的路径规律:groupId/artifactId/version/groupId-version

依赖仓库

groupId、artifactId、version为基本坐标

type为依赖类型,默认为jar

scope为依赖范围

compile:编译,测试,运行三种classpath都有效 test:只对测试有效 provided:编译和测试有效 runtime:测试和运行有效 system:系统依赖,依赖的包是从计算机本地导入,与systemPath配合使用 ​ <systemPath>${java.home}/lib/rt.jar</systemPath><scope>system</scope>

传递性依赖

maven默认就是支持的。

什么是传递性依赖?

比如:现在要导入A.jar包,但A.jar有依赖于B.jar,在maven中就会默认导入B.jar,而不需要手动去导入。

scope最好设为compile

传递性依赖存在一个问题:工程中存在两个jar分别依赖的是B.jar的不同版本jar包,就会出现错误。

optional:可选依赖,true 不会传递,false会传递(默认)

<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.10</version>
<optional>true</optional>
</dependency>

当其他项目C依赖B项目时,mysql-connector-java的依赖不会发生传递给C

优点:

减少冲突,不用的功能不传递

一个jar应该只有 一个职责原则

exclusions排除依赖

用于替换某个 依赖中的依赖包作用

<dependencies>
    <dependency>
        <groupId>com.juv</groupId>
        <artifactId>project-B</artifactId>
        <version>1.0.0</version>
        <exclusions>
            <exclusion>//可以有多个
                <groupId>com.juv</groupId>
                <artifactId>project-C</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>com.juv</groupId>
        <artifactId>project-B</artifactId>
        <version>1.1.0</version>
    </dependency>
</dependencies>

该例子的意思:不想使用project-B中版本的project-C依赖包,而将其环卫1.1.0的project-C包

归类依赖

场景:存在一群版本号一致的依赖,想通过一个统一的配置,将其统一配置和修改

<properties>
    <spring>2.5.6</spring>
</properties>

调用方式

<version>${spring}</version>

部署至远程仓库

修改工程中的pom文件

<project>
    ....
    <distributionManagement>
     	<repository>  //发布版本构件的仓库
            <id></id>  //远程仓库的唯一标识
            <name></name>   //自定义
            <url></url>   //该仓库地址
        </repository>
     	<snapshotRepository>//快照版本的设置
            <id></id>
            <name></name>
            <url></url>   
        </snapshotRepository>
    </distributionManagement>
    ....
</project>

如果需要认证,则在setting.xml文件中增加一个元素进行配置

在配置完成后,执行mvn clean deploy 就会根据当前版本类型,发布到相应的仓库中

快照版本

快照不是正式版本,当设为带有SNAPSHOT的version时,即为快照版本,每次向仓库部署是,会自动打上时间戳,其他引用快照相同版本时会自动下载更新

例如:2.1-SNAPSHOT时,则会下载2.1-20091214之类的构件

在maven本地仓库的groupId/artifactId/version文件路径下会存在maven-metadata.xml文件,会记录版本信息

<?xml version="1.0" encoding="UTF-8"?>
<metadata>
  <groupId>com.android.support</groupId>
  <artifactId>multidex</artifactId>
  <version>1.0.0</version>
  <versioning>
    <versions>
      <version>1.0.0</version>
      <version>1.0.1</version>
    </versions>
    <lastUpdated>20141209014044</lastUpdated>
  </versioning>
</metadata>

maven生命周期

maven的生命周期是抽象的,其实际行为都是由插件来完成的。

maven的生命周期是不做任何实际工作,实际任务都由插件完成。

maven具有三个独立的生命周期:clean、defeat、site

1、clean生命周期:清理项目,包含三个phase。

1)pre-clean:执行清理前需要完成的工作 2)clean:清理上一次构建生成的文件 3)post-clean:执行清理后需要完成的工作

2、default生命周期:构建项目,重要的phase如下。

1)validate:验证工程是否正确,所有需要的资源是否可用。 2)compile:编译项目的源代码。 3)test:使用合适的单元测试框架来测试已编译的源代码。这些测试不需要已打包和布署。 4)Package:把已编译的代码打包成可发布的格式,比如jar。 5)integration-test:如有需要,将包处理和发布到一个能够进行集成测试的环境。 6)verify:运行所有检查,验证包是否有效且达到质量标准。 7)install:把包安装到maven本地仓库,可以被其他工程作为依赖来使用。 8)Deploy:在集成或者发布环境下执行,将最终版本的包拷贝到远程的repository,使得其他的开发者或者工程可以共享。

3、site生命周期:建立和发布项目站点,phase如下

1)pre-site:生成项目站点之前需要完成的工作 2)site:生成项目站点文档 3)post-site:生成项目站点之后需要完成的工作 4)site-deploy:将项目站点发布到服务器

命令行输入:$mvn clean 其实调用的是clean生命周期的clean阶段,执行了pre-clean和clean

而这些命令其实是由插件提供功能的。

自定义绑定插件

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>//maven官方,官方的可以省略该标签
            <artifactId>maven-source-plugin</artifactId>//插件
            <version>2.1.1</version>//没有version时,会默认下载最新的release版本
          <executions>//配置执行n个任务
                <execution>
                   	<id>attach-sources</id>//可以任意
                   	<phase>verify</phase>//绑定到verify生命周期,在此时才会起作用
                    <goals>
                       	<goal>jar-no-fork</goal>//启用该插件的jar-no-fork功能
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>
</build>

因为一个插件可能存在多个功能,但我们并不一定所有的功能都需要,所以设定goal标签,表示我们要实现的功能。

插件配置

命令行配置:$mvn install -Dt 插件相关参数 //适用于当每次运行时,这个插件的配置都会变的情况

pom中全局配置:

<build>
    <plugins>
        <plugin>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.1</version>
            <configuration>
              <source>1.7</source>  //jdk1.7
              <target>1.7</target> //编译后jdk1.7
            </configuration>
        </plugin>
    </plugins>
</build>

聚合(多模块)

意义:一次构建所有想要构建的项目

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.son.nexus</groupId>
    <artifactId>nexus-indexer</artifactId>
    <version>2.0.0</version>
    <packaging>pom</packaging>//本身也是一个maven工程
    <modules>
      	<module>account-email</module>//想要构建的项目,这里写的是当前pom文件下的相对路径地址
        <module>account-persilist</module>
    </modules>
</project>

聚合pom文件的packaging标签一定要是pom,其工程就只是一个pom文件,没有其他的实现代码

一般来说模块处的目录名应与其artifactId一致

聚合模块与其他模块的目录结构并非一定要父子关系

继承

父pom

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.son.nexus</groupId>
    <artifactId>nexus-indexer</artifactId>
    <version>2.0.0</version>
    <packaging>pom</packaging>//本身也是一个maven工程
 	<dependencies>
        <dependency>
            <groupId>com.juv</groupId>
            <artifactId>project-B</artifactId>
            <version>1.0.0</version>
            <exclusions>
                <exclusion>
                    <groupId>com.juv</groupId>
                    <artifactId>project-C</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupId>com.juv</groupId>
            <artifactId>project-B</artifactId>
            <version>1.1.0</version>
        </dependency>
	</dependencies>
</project>

父pom的packaging也是pom

子pom

<project>
	<modelVersion>4.0.0</modelVersion>
    <groupId>org.son.nexus</groupId>
    <artifactId>nexus-B</artifactId>
    <version>2.0.0</version>
    <packaging>jar</packaging>
	<parent>
		<groupId>org.son.nexus</groupId>
		<artifactId>nexus-C</artifactId>
		<version>1.0.0-SNAPSHOT</version>
        <relativePath>../pom.xml</relativePath>//相对路径
	</parent>
</project>

子pom的packaging则不一定要是pom,但一定有parent标签

子类的groupId和version也可以继承与父pom文件

标签

作用:当子类不需要父pom中的某些依赖的时,就可以使用。

父pom

<dependencyManagement>
	<dependencies>
		<dependency>
			<artifactId>spring-core</artifactId>
			<groupId>org.springframework</groupId>
			<version>3.1.1.RELEASE</version>
		</dependency>
     </dependencies>
</dependencyManagement>

被标签所包裹的依赖是不会主动被加载进入子pom中,只有子pom中显式再次声明的时候才会被依赖

子pom

<dependencies>
    <dependency>
        <artifactId>spring-core</artifactId>
        <groupId>org.springframework</groupId>
    </dependency>
</dependencies>

可以省略version等其他配置,因为父pom中已经配置过了

若想获取父pom中所有的dependencyManagement中的构件配置,则在子pom中如下配置

<dependencyManagement>
	<dependencies>
		<dependency>
			<artifactId>account-parent</artifactId>
			<groupId>com.juvenxu.accout</groupId>
			<version>3.1.1.RELEASE</version>
			<type>pom</type>
			<scope>import</scope>
		</dependency>
     </dependencies>
</dependencyManagement>

配置父pom的一些信息

插件管理

父pom中的插件不想在子类中默认使用

跟依赖管理一样,被包裹的插件配置不会被子pom主动获取,只有当子pom中声明了该插件的groupId和artifactId后,才会被继承

一个pom文件既可以是聚合也可以是父pom

反应堆

在聚合构建时,构件模块的先后顺序的排列。

按书写的先后顺序进行构建

加料区

如果同一个项目中存在多个模块相互依赖时候,version和groupId可以使用\${project.groupId}(当前模块的groupId)和${project.verison},这样就不用不断的更改了。

标签用来确定最终包名

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券