本文介绍如何让 Gradle 项目在同一构建中正确启用并测试其自定义注解处理器（如 MyAnnotationProcessor），解决“在 src/test/ 中使用 @MyAnnotation 却无任何处理日志”的常见问题。核心方案是拆分模块，使处理器与测试代码分离，规避编译期循环依赖限制。
本文介绍如何让 gradle 项目在**同一构建中**正确启用并测试其自定义注解处理器（如 `myannotationprocessor`），解决“在 `src/test/` 中使用 `@myannotation` 却无任何处理日志”的常见问题。核心方案是拆分模块，使处理器与测试代码分离，规避编译期循环依赖限制。
在 Gradle 中，一个模块无法直接将自身 src/main/ 中定义的注解处理器用于自身的 src/test/ 编译过程。原因在于：Gradle 的 Java 插件默认将 annotationProcessor 依赖解析为外部 JAR 包，而 project(':lib') 在 test 阶段尚未完成编译（classes 任务未执行完毕），导致 testAnnotationProcessor 无法识别或加载 lib 模块中尚未生成的处理器类。即使使用 annotationProcessor project(':lib')，也会因 classpath 时机问题静默失败——你不会看到错误，但 processingEnv.getMessager().printMessage(...) 完全不会触发。
✅ 推荐且稳定可行的解决方案是：采用多模块结构，将注解处理器定义在 lib 模块，测试逻辑移至独立的 test（或 processor-test）模块。该方式符合 Gradle 构建生命周期，确保 lib 先编译、发布（到构建缓存），再被 test 模块以 testAnnotationProcessor 形式引用。
✅ 正确目录结构与配置
. ├── lib/ │ ├── build.gradle │ └── src/main/java/demo/ │ ├── MyAnnotation.java │ └── MyAnnotationProcessor.java ├── test/ │ ├── build.gradle │ └── src/test/java/demo/MyAnnotationProcessorTest.java └── settings.gradle
1. settings.gradle 启用双模块
include('lib', 'test')
2. lib/build.gradle —— 仅声明处理器实现
plugins {
id 'java-library'
}
repositories { mavenCentral() }
dependencies {
// 注解处理器运行时依赖（如 AutoService）
implementation 'com.google.auto.service:auto-service:1.1.1'
annotationProcessor 'com.google.auto.service:auto-service:1.1.1'
// ⚠️ 注意：此处不添加 test 相关依赖，保持模块职责单一
}
java {
toolchain { languageVersion = JavaLanguageVersion.of(17) }
}
3. test/build.gradle —— 专注测试验证
plugins { id 'java' }
repositories { mavenCentral() }
dependencies {
testImplementation 'org.junit.jupiter:junit-jupiter:5.9.1'
testImplementation project(':lib') // 提供 @MyAnnotation 等 API
testAnnotationProcessor project(':lib') // ✅ 关键：让注解处理器参与 test 编译
}
java {
toolchain { languageVersion = JavaLanguageVersion.of(17) }
}
tasks.named('test') {
useJUnitPlatform()
}
? 为什么
testAnnotationProcessor project(':lib')有效？
因为 Gradle 会自动确保lib:classes和lib:jar（含META-INF/services/javax.annotation.processing.Processor）在test:compileTestJava之前完成。此时test模块的编译器能正确发现并加载MyAnnotationProcessor，并在遇到@MyAnnotation时触发process()方法——你会在控制台看到">>>>> process called 日志。
? 验证是否生效
在 test/src/test/java/demo/MyAnnotationProcessorTest.java 中添加测试用例：
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
package demo;
import org.junit.jupiter.api.Test;
@MyAnnotation
class MyAnnotationProcessorTest {
@Test
@MyAnnotation
void testWithAnnotation() {
@MyAnnotation String s = "hello";
}
}
运行 ./gradlew test --info，观察编译日志中是否出现 >>>>> process called 。若出现，则证明处理器已成功介入测试源码的编译阶段。
⚠️ 注意事项与最佳实践
-
test模块不会打包进最终发布的lib.jar：test是独立模块，其内容（包括MyAnnotationProcessorTest.class）仅存在于test/build/下，不影响lib的发布产物。 -
避免在
lib中写测试逻辑：lib/src/test/仅适合单元测试处理器内部逻辑（如模拟RoundEnvironment），不能验证注解处理行为本身——因为lib无法处理自己的注解。 -
替代方案（不推荐）：尝试
compileOnly files('build/classes/java/main')或gradle.properties中 hack classpath，极易因构建缓存、增量编译失效，且不可靠。 -
进阶建议：若需更高保真度测试（如生成文件校验），可在
test模块中添加compileTestJava任务的doLast钩子，检查build/generated/sources/annotationProcessor/test/目录是否存在预期输出。
通过模块化拆分，你不仅解决了自测难题，还提升了项目结构清晰度和可维护性——这正是现代 Gradle 工程实践所倡导的「关注点分离」原则的体现。
