Maven

1. 概述 Maven 利用插件来自动化和执行所有的构建和生成报告的任务。 然而，项目中可能由多个相同的插件，它们的配置和版本都不一样，特别在多模块的项目中，这会让项目变得复杂，难以维护。 2. 插件配置 Maven 有两种类型的插件： Build - 在构建过程中执行，例如 Clean、Install 和 Surefire 插件，这些插件应该被配置在 pom 文件的 build 部分。 Reporting - 在 site 阶段执行来生成多个项目报告，例如 Javadoc 和 Checkstyle 插件，这些在 pom 文件的 reporting 部分配置。 我们可以在 pom 文件中声明 jar 插件，用来将我们的项目打包成 jar 文件： 1 2 3 4 5 6 7 8 9 <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <version>3.2.0</version> </plugin> </plugins> </build> 3. 插件管理 我们也可以在 pluginManagement 标签内声明插件。 如果在 pluginManagement 标签内声明插件，它将会对所有的子 POM 文件生效。 这意味着在子 pom 文件中不需要显示指定版本号，同时也不会有重复的配置或冲突的版本。 和依赖管理一样，在多模块项目中使用该方法非常有用。 4. 示例 下面是一个包含两个子模块的多模块项目。 在父 POM 文件中，我们添加了 Build Helper 插件。 4.1. 父 POM 文件 首先，在父 POM 文件的 pluginManagement 部分添加插件 该插件将 add-resource 目标绑定到 generate-resources 阶段 同样，我们也指定 src/resources 目录作为包含额外资源的目录 该插件会将资源拷贝到目标位置 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 <pluginManagement> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> <version>3.3.0</version> <executions> <execution> <id>add-resource</id> <phase>generate-resources</phase> <goals> <goal>add-resource</goal> </goals> <configuration> <resources> <resource> <directory>src/resources</directory> <targetPath>json</targetPath> </resource> </resources> </configuration> </execution> </executions> </plugin> </plugins> </pluginManagement> 4.2. 子 POM 配置 现在在子 POM 文件中引用该插件： 1 2 3 4 5 6 7 8 <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>build-helper-maven-plugin</artifactId> </plugin> </plugins> </build> 和依赖管理相似，我们不需要指定任何插件的版本号，因为它们会从父 POM 文件中集成。 5. 核心插件 有一些 Maven 核心配置在整个生命周期中被默认使用，例如 clean 和 compiler 插件不需要被显式指定。 然而我们可以在 pluginManagement 中显式指定这些信息。 主要的区别在于核心插件默认会生效并自动执行，并不需要在子项目中传递引用。 下面我们在 pluginManage 中添加编译插件： 1 2 3 4 5 6 7 8 9 10 11 <pluginManagement> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.10.0</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin> </pluginManagement> 这里我们锁定了插件的版本号，并且配置使用 Java 8 来构建项目，然而我们并不需要在子项目中额外声明插件。 构建框架默认激活这些配置。 因此，推荐在多模块项目中在 pluginManagement 中显式指定插件的配置并且锁定插件的版本。

1. 概述 本文将会探索不同的 Maven 构建声明周期和它们的阶段。 也会深入讨论目标和阶段之间的核心关联。 2. Maven 构建生命周期 Maven 构建遵循一个指定的生命周期来部署和分发目标项目 有三种内置的生命周期： 默认(default)：主生命周期，负责项目的部署。 清理(clean)：清理项目并且移除所有由先前的构建产生的文件。 建立站点(site)：创建整个项目的文档 每个生命周期由若干个阶段(phase)组成，默认的构建生命周期包含 23 个阶段 clean 生命周期包含三个阶段，site 生命周期包含 4 个阶段 3. Maven 阶段 一个 Maven 阶段代表 Maven 构建生命周期其中的一个步骤。 每一个阶段都代表一个指定的任务。 默认生命周期下关键的一些阶段如下： validate：检查所有供构建需要的必要信息都足够完备 compile：编译源代码 test-compile：编译测试源代码 test：运行单元测试 package：将编译后的源代码进行打包 integration-test：如果需要运行集成测试，则处理和部署包 install：将包安装到本地仓库 deploy：将包复制到远程仓库 阶段按照指定的顺序指定，也就是说，如果我们执行命令 mvn <phase> 那么它不仅仅会只执行指定的阶段，也会执行前置的所有阶段。 例如，如果我们运行部署阶段，那么它会执行之前的所有完整阶段 4. Maven 目标(Goal) 每一个阶段都是由一系列目标构成的，每一个阶段都对应一个指定的任务。 当我们执行一个阶段时，所有绑定到该阶段上的目标都被按顺序执行（在 POM 文件中定义的顺序）。 下面是一些阶段和该阶段上绑定的默认的目标 compiler:compile：编译插件上的编译目标被绑定到编译阶段 compiler:testCompile: 被绑定到 test-compile 阶段 surefire:test: 被绑定到 test 阶段 install: 被绑定到 install 阶段 jar:jar 和 war:war： 被绑定到 package 阶段 可以使用命令 mvn help:describe -Dcmd=PHASENAME 来列出绑定到某一个阶段的目标和插件 5. Maven 插件 Maven 插件是一组目标，然而这些目标不必绑定到相同的阶段。 例如，下面是 Maven Failsafe 插件的简单配置，它被用来执行集成测试： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 <build> <plugins> <plugin> <artifactId>maven-failsafe-plugin</artifactId> <version>${maven.failsafe.version}</version> <executions> <execution> <goals> <goal>integration-test</goal> <goal>verify</goal> </goals> </execution> </executions> </plugin> </plugins> </build> 可以看到，Failsafe 插件配置了两个主要的目标： ...

1. 概述 本文主要描述 Maven 多模块项目如何创建。 描述什么是多模块项目以及使用该方法的好处。 2. Maven 的多模块项目 一个多模块项目根据一个聚合 pom 文件构建，该文件管理一组子模块。 在大多数情况下，聚合 pom 文件位于项目的根目录下，并且打包方式为 pom。 子模块是常规的 Maven 项目，并且它们也能被单独构建。 通过聚合 POM 来构建项目，每个打包方式不为 pom 的项目都会被打包进最终的项目文件中。 3. 使用多模块的好处 最显著的好处是我们能够减少重复和冲突。 假设我们有包含若干个模块的应用程序，一个前端模块和一个后端模块。 现在想象我们在它们之上构建项目，并且修改配置对二者都生效的配置项，使用多模块就很容易办到。 4. 父 POM Maven 通过让每个 pom 文件都有父 pom 文件来支持继承。 除了继承，Maven 还提供了聚合的概念，一个支持聚合的父 POM 文件被称为聚合 POM，这种 POM 在它的 pom 文件中声明聚合的模块。 5. 子模块 子模块，或者子项目，是继承自父 POM 文件的常规项目。 继承可以让子项目共享配置和依赖。 然而，如果我们想要一起编译和发布项目，就必须要在父 POM 文件中显式声明。 6. 构建应用程序 现在我们创建一个程序来演示这项功能，该程序包含三个模块： ...

1. 概述 下面的内容将描述 Maven 的依赖作用域-它能帮助 Maven 解决间接依赖。 2. 间接依赖 Maven 中有两种形式的依赖：直接依赖和间接依赖。 直接依赖是我们在项目中显式声明的依赖，例如： 1 2 3 4 5 <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> </dependency> 间接依赖就是直接依赖的依赖。 Maven 会自动导入项目中的间接依赖。 可以使用 mvn dependency:tree 来列出项目中的所有依赖： 1 2 3 4 5 6 7 8 9 10 [INFO] --- maven-dependency-plugin:2.8:tree (default-cli) @ demo01 --- [INFO] com.ans20xx:demo01:jar:1.0-SNAPSHOT [INFO] \- junit:junit:jar:4.11:test [INFO] \- org.hamcrest:hamcrest-core:jar:1.3:test [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.566 s [INFO] Finished at: 2023-02-04T09:33:56+08:00 [INFO] ------------------------------------------------------------------------ 3. 依赖作用域 依赖作用域可以被用来限制间接依赖。 依赖作用域也会根据不同的构建任务来修改 classpath。 Maven 有六种依赖作用域。 除了 import 作用域之外的其他作用域都会对间接依赖产生影响。 3.1. compile 作用域 当没有显式指定作用域时，compile 是默认的作用域。 在该作用域上的依赖会出现在所有的构建任务中的 classpath 内。 这些依赖也会被传递给子项目。 3.2. provided 作用域 使用 provided 作用域表示该依赖在运行时由 JDK 或容器提供。 该作用域的一个使用例子是在容器中部署 web 应用，而这些容器本身也提供了一些依赖，例如 tomcat 容器本身会提供 servlet api。 1 2 3 4 5 6 <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> provided 作用域的依赖值存在与 compile 和 test 的 classpath 中，在打包时并不会打到包中。 该作用域的依赖不可传递。 3.3. Runtime 作用域 该作用域下的依赖在运行时需要，但是我们在编译期不需要。 所以，该作用域下的依赖会出现在运行时和测试的 classpath 中，但不会出现在编译时的 classpath 中。 jdk 驱动就是运行时需要的依赖： 1 2 3 4 5 6 <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.28</version> <scope>runtime</scope> </dependency> 3.4. Test 作用域 该作用域用来说明依赖只有在测试时才需要。 测试作用域下的依赖是不可传递的，只出现在 test 和 execution classpath 中。 JUnit 是一个典型的例子： 1 2 3 4 5 6 <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> 3.5. System 作用域 System 作用域和 Provided 作用域非常类似。 区别在于 System 作用域需要我们直接指定系统中的某个指定的 jar 包。 然而，需要注意的是 System 作用域已经被废弃了，因为它会让在不同机器上指定的值都不相同。 1 2 3 4 5 6 7 <dependency> <groupId>com.baeldung</groupId> <artifactId>custom-dependency</artifactId> <version>1.3.2</version> <scope>system</scope> <systemPath>${project.basedir}/libs/custom-dependency-1.3.2.jar</systemPath> </dependency> 3.6. Import 作用域 import 作用域仅适用于 pom 类型的依赖。 import 说明该依赖应该被替换为声明在该 pom 文件中的所有有效依赖。 下面的例子中，customer-project 依赖会被替换为在 customer-project 的 pom 文件中 <dependencyManagement> 元素内的所有依赖： 1 2 3 4 5 6 7 <dependency> <groupId>com.baeldung</groupId> <artifactId>custom-dependency</artifactId> <version>1.3.2</version> <scope>system</scope> <systemPath>${project.basedir}/libs/custom-dependency-1.3.2.jar</systemPath> </dependency> 4. 作用域和传递性 每个依赖作用域都会影响间接依赖。 也就是说，间接依赖最终会以不同的作用域出现在项目中。 然而，provided 和 test 作用域的依赖并不会被包含在主项目中。 对于 compile 作用域，所有 runtime 作用域的依赖将会以 runtime 作用域被添加到项目中，所有 compile 作用域的依赖将会以 compile 作用域被添加到项目中。 对于 provided 作用域，所有 runtime 和 compile 作用域的依赖都会以 provided 作用域被添加到项目中。 对于 test 作用域，所有 runtime 和 compile 作用域的依赖都会以 test 作用域添加到项目中。 对于 runtime 作用域，所有 runtime 和 compile 作用域的依赖都会以 runtime 作用域添加到项目中。 https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

1. 概述 Maven Profile 可以被用来创建自定义的构建配置，例如指定一个测试粒度，或者是指定部署环境。 ...

1. 简介 Apache Maven 除了分离依赖和仓库外，还提供了一个标准的工程目录结构。 ...

1. 构建应用程序 构建一个应用程序往往由以下几个步骤组成： 下载依赖 将依赖 jar 包放在 classpath 目录下 将源代码编译为二进制码 运行测试 将编译结果打包成可部署的软件包：jar、war 等 将工程发布到服务器或者仓库中 Apache Maven 将这些步骤自动化，减少了人工操作带来的错误 2. 为什么用 Maven Maven 有如下优势： ...