Maven学习（十一）POM深入与强化-build标签详解

1.一睹真容

在实际使用Maven的过程中，我们会发现build标签有时候有，有时候没有，这是怎么回事呢？其实通过有效POM我们能够看到，build标签其实一直都在，只是在我们需要定制构建过程的时候才会通过配置build标签覆盖默认值或者补充配置。这一点我们可以通过打印有效POM来看。

所以本质上来说，我们配置的build标签都是对超级POM配置的叠加。那么我们又为什么在默认的配置的基础上叠加呢？很简单，在默认配置无法满足需求的时候定制构建过程。

2.build标签组成

从完整示例可以看出，build标签大概包含三个主题部分

①定义约定的目录结构

参考：

②备用插件管理

pluginsManagement标签存放着几个极少用到的插件：

• maven-antrun-plugin
• maven-assembly-plugin
• maven-dependency-plugin
• maven-release-plugin

通过pluginsManagement标签管理起来的插件就像 dependencyManagement一样，子工程使用时可以省去版本号，在父工程中统一管理

• 被spring-boot-dependencies管理的插件信息

<plugin>
	<groupId>org.springframework.bootgroupId>
	<artifactId>spring-boot-maven-pluginartifactId>
	<version>2.6.2version>
plugin>

• 子工程使用的插件信息

  
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.bootgroupId>
                <artifactId>spring-boot-maven-pluginartifactId>
            plugin>
        plugins>
    build>

③生命周期插件

plugins标签存放的是默认生命周期中实际会使用到的插件，这些插件想必大家都不陌生，所以抛开插件本身不谈，我们来看看plugin标签的结构

【1】坐标部分

artifactId和version标签定义了插件的坐标，作为Maven的自带插件这里省略了groupId。

【2】执行部分

executions标签内部可以配置多个execution标签，execution标签内部为：

• id：唯一标识
• phase：关联的声明周期阶段
• goals/goal : 关联指定生命周期的目标

可是这么多个目标，又该执行哪一个呢？
所以从逻辑和实际功能运行情况的角度来看，应该是生命周期的一个环节对应插件的一个目标，目前也没有看到goals中有多个goal的。
另外，插件目标的执行过程可以进行配置，例如maven-site-plugin插件的site目标：

结论：每个插件能够做哪些设置，都是各个插件自行规定的，无法一概而论。

3.典型应用：指定JDK版本

①提出问题

前面我们在setting.xml中配置了jdk版本，那么将来把Maven工程部署到服务器上，脱离了settings.xml配置，如何保证程序正常运行呢？思路就是我们直接把JDK版本信息告诉负责编译的Maven-compile-plugin插件，让它在构建中，按照我们制定的信息操作。

②这暂时取消settings.xml的配置

注释掉setting.xml中的这部分

  <profiles>
     <profile>
            <id>jdk-1.8id>
            <activation>
                <activeByDefault>trueactiveByDefault>
                <jdk>1.8jdk>
            activation>
            <properties>
              <maven.compiler.source>1.8maven.compiler.source>
              <maven.compiler.target>1.8maven.compiler.target>
              <maven.compiler.complerVersion>1.8maven.compiler.complerVersion>
            properties>
        profile>
  profiles>

③配置构建过程

  
  <build>
    
    <finalName>pro02-maven-webfinalName>
    
    <plugins>
      
      <plugin>
        
        <groupId>org.apache.maven.pluginsgroupId>
        <artifactId>maven-compiler-pluginartifactId>
        <version>3.1version>
        
        <configuration>
          <source>1.8source>
          <target>1.8target>
          <encoding>UTF-8encoding>
        configuration>
      plugin>
    plugins>
  build>

④两种配置方式的比较

• 在settings.xml中配置：仅在本地生效，意思就是我创建的工程，只能我打包，才能遵循这个配置，要是别人拉了代码，但是settings的配置和我不一样，那可能打包编译都会报错。
• 在当前Maven工程的pom.xml中配置：无论哪个环境都能生效。

4.典型应用：Springboot定制化打包

比如添加springboot特定的插件，可以构建可运行的springboot的jar包

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.bootgroupId>
                <artifactId>spring-boot-maven-pluginartifactId>
            plugin>
        plugins>
    build>

5.小结

通常需要用到的build标签的时候底层都会帮我们封装好，需要我们配置的地方不多。即使有些地方需要我们配置，也不会真的我们自己去写，把现成的案例复制过来就行。
但要能看懂build标签的含义和用途。