CrabNote螃蟹笔记

Maven 最佳实践

> 本文由 JavaGuide 翻译并完善,原文地址:<https://medium.com/@AlexanderObregon/maven-best-practices-tips-and-trick

本文由 JavaGuide 翻译并完善,原文地址:<https://medium.com/@AlexanderObregon/maven best practices tips and tricks for java developers 438eca03f72b 。 Maven 是一种广泛使用的 Java 项目构建自动化工具。它简化了构建过程,并帮助我们管理依赖关系。Maven 详细介绍可以参考这篇文章:Maven 核心概念总结。 这篇文章不展开 Maven 基础概念,主要讨论项目中更容易踩坑的实践问题:目录结构、编译版本、依赖版本、环境配置、Wrapper、CI 和插件管理。 Maven 标准目录结构 Maven 遵循标准目录结构来保持项目之间的一致性。遵循这种结构可以让其他开发人员更轻松地理解我们的项目。 Maven 项目的标准目录结构如下: :源代码目录 :资源文件目录 :测试代码目录 :测试资源文件目录 这只是一个最简单的 Maven 项目目录示例。实际项目中,我们还会根据项目规范去做进一步的细分。 明确指定 Java 编译版本 不要依赖 Maven 或插件的默认编译版本,项目应该在 中明确声明目标 Java 版本。对于现代 Java 项目,优先使用 ,它对应 ,比单独配置 和 更稳妥。 需要注意的是, 从 JDK 9 开始提供;Maven Compiler Plugin 3.13.0 及之后版本在 JDK 8 上也支持 ,会自动转换为 和 。如果项目仍使用更旧的插件或构建环境,再显式配置 、 。 例如,项目需要按 Java 17 编译,可以这样写: 如果需要直接配置 Maven Compiler Plugin,也可以这样写: 的值不要再写成 这种旧格式。比如 Java 8 写 ,Java 17 写 ,Java 21 写 。 有效管理依赖关系 Maven 的依赖管理系统是其最强大的功能之一。在父 POM 中,通过 定义公共依赖版本,可以避免多个模块各写一份版本号,降低依赖冲突概率。 例如,假设我们有一个父模块和两个子模块 A 和 B,想要在所有模块中使用 JUnit 5,可以在父模块的 文件中通过 定义 JUnit 的版本: 在子模块 A 和 B 的 文件中,只需要引用 JUnit 的 和 即可: 对于 Spring Boot、Spring Cloud 这类已经提供 BOM 的生态,优先导入官方 BOM,再在业务模块里省略具体依赖版本。这样能减少“手工拼版本”带来的兼容性问题。 针对不同环境使用配置文件 Maven 配置文件允许我们配置不同环境的构建设置,例如开发、测试和生产。在 文件中定义配置文件并使用命令行参数激活它们: 使用命令行激活配置文件: 保持 pom.xml 干净且井然有序 组织良好的 文件更易于维护和理解。以下是维护干净的 的一些技巧: 将相似的依赖项和插件组合在一起。 使用注释来描述特定依赖项或插件的用途。 将公共版本号放在 标签内,或者统一放到父 POM 的 / 中管理。 插件版本也建议显式声明。不要依赖 Maven 的默认插件版本,否则不同 Maven 版本或不同构建环境下可能出现行为差异。 使用 Maven Wrapper Maven Wrapper 是一个用于管理和使用 Maven 的工具,它允许在没有预先安装 Maven 的情况下运行和构建 Maven 项目。 Maven 官方文档是这样介绍 Maven Wrapper 的: The Maven Wrapper is an easy way to ensure a user of your Maven build has everything necessary to run your Maven build. Maven Wrapper 是一种简单的方法,可以确保 Maven 构建的用户拥有运行 Maven 构建所需的一切。 Maven Wrapper 可以确保构建过程使用正确的 Maven 版本,非常方便。要使用 Maven Wrapper,请在项目目录中运行以下命令: 此命令会在我们的项目中生成 Maven Wrapper 文件。现在我们可以使用 (或 Windows 上的 )而不是 来执行 Maven 命令。 团队项目建议提交 、 和 目录。这样新成员或 CI 环境不需要预先安装指定版本的 Maven,也能用项目声明的 Maven 版本完成构建。 通过持续集成实现构建自动化 将 Maven 项目与持续集成 (CI) 系统(例如 Jenkins 或 GitHub Actions)集成,可确保自动构建、测试和部署我们的代码。CI 有助于及早发现问题并在整个团队中提供一致的构建流程。以下是 Maven 项目的简单 GitHub Actions 工作流程示例: CI 中建议使用 ,它会执行测试和必要的校验流程。 会把构建产物安装到本地仓库,只有后续步骤确实依赖本地安装结果时才需要使用。 利用 Maven 插件获得附加功能 有许多 Maven 插件可用于扩展 Maven 的功能。一些流行的插件包括(前三个是 Maven 自带的插件,后三个是第三方提供的插件): maven surefire plugin:配置并执行单元测试。 maven failsafe plugin:配置并执行集成测试。 maven javadoc plugin:生成 Javadoc 格式的项目文档。 maven checkstyle plugin:强制执行编码标准和最佳实践。 jacoco maven plugin:单测覆盖率。 sonar maven plugin:分析代码质量。 …… jacoco maven plugin 使用示例: 如果这些已有的插件无法满足我们的需求,我们还可以自定义插件。 探索可用的插件并在 文件中配置它们以增强我们的开发过程。 总结 Maven 最重要的不是“能不能把项目跑起来”,而是让团队在本地、CI 和部署环境中使用一致的构建方式。实际项目里,建议优先做好这几件事:使用标准目录结构,显式声明 Java 和插件版本,通过父 POM、BOM、 管理依赖版本,提交 Maven Wrapper,并在 CI 中固定 JDK 和 Maven 构建命令。