Gradle怎么迁移现有的Maven Java项目-java教程-PHP中文网

执行 gradle init --type=pom 后需立即检查三件事：1. settings.gradle 是否完整包含多模块；2. 依赖作用域是否按 api/implementation 正确划分；3. 源码路径是否与 pom.xml 中 sourceDirectory 一致。

gradle怎么迁移现有的maven java项目

能直接用 gradle init --type=pom 自动生成基础配置，但生成的 build.gradle 通常不能直接跑通——尤其涉及多模块、自定义插件、profile 或 Java 模块系统（module-info.java）时，必须手动修正。

执行 `gradle init --type=pom` 后要立刻检查的三件事

这个命令会读取当前目录下的 pom.xml，生成 build.gradle、settings.gradle 和基本目录结构。但它不解析 Maven 的 profiles，也不处理 pluginManagement 块或 dependencyManagement 中的 BOM 导入。

检查 settings.gradle：若原项目是多模块（如 parent/pom.xml + child1/, child2/），gradle init 可能只生成单模块脚本，需手动补全 include 'child1', 'child2'
核对依赖作用域：Maven 的 compile 会被默认转成 implementation，但若该依赖实际被子类或 API 方法暴露（比如你写了 public class X { public Y method() { ... } }，而 Y 来自某依赖），就得改用 api 配置，否则编译会失败
确认源码路径是否被覆盖：某些老 pom.xml 用自定义了 Java 路径，gradle init 不识别，生成的 build.gradle 仍默认读 src/main/java，结果编译报 “package not found”

`java-library` 插件 vs `java` 插件：选错就导出不了 API

如果你的项目对外提供 SDK 或被其他模块依赖，必须用 java-library 插件，而不是基础的 java 插件。后者没有 api 和 implementation 的区分，所有依赖都变成 compileClasspath，导致下游模块编译时找不到间接依赖。

在 build.gradle 中替换：plugins { id 'java' } → plugins { id 'java-library' }
同时把 dependencies 块里暴露给调用方的依赖（如 Guava 的 ImmutableList 被你公开返回）移到 api 下；仅内部使用的（如 Logback 实现）留在 implementation
如果用了 module-info.java，还必须加 modularity.inferModulePath.set(true)，否则 JPMS 模块解析失败，报 module not found

Spring Boot 项目迁移时最常漏掉的两处配置

Spring Boot 的 Maven 父 POM（如 spring-boot-starter-parent）自带依赖版本管理、插件预设和资源过滤逻辑，Gradle 不会自动继承这些。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

显式引入 Spring Boot Gradle 插件：plugins { id 'org.springframework.boot' version '3.3.4'}（版本需与你原 pom.xml 中对齐）
补全 dependencyManagement：若原 pom.xml 用了 spring-boot-dependencies BOM，需在 build.gradle 加 ext['spring-boot.version'] = '3.3.4' 并启用 io.spring.dependency-management 插件，否则 spring-boot-starter-web 之类可能拉错传递依赖版本

验证迁移是否真正完成的硬指标

别只看 gradle build 能过——那只是编译+测试通过。真正的完成标准是下游消费行为一致：

用 Gradle 构建出的 JAR 必须能被另一个 Maven 项目正常引入，并且其公开类（含泛型签名、注解、module-info.java）可被正确解析
原 mvn clean install 会把构件推到本地 ~/.m2/repository，对应 Gradle 要执行 gradle publishToMavenLocal，且生成的 pom-default.xml 中 // 必须与 Maven 完全一致，否则下游 mvn 找不到
CI 流水线中若原来跑 mvn verify，现在得确保 gradle check 触发同样检查项（如 Checkstyle、JaCoCo 覆盖率阈值），这些插件配置不会被 init 命令带过来

模块化项目里最容易被忽略的是 requires static 语句的兼容性——Gradle 默认不把 test 依赖暴露给主模块，但如果你在 module-info.java 里写了 requires static org.junit.jupiter.api，就得在 build.gradle 显式配置 testRuntimeOnly 并确保模块图解析时包含它，否则 jlink 或运行时模块加载会失败。