Maven Compiler插件未调用javac 引入自定义shaded依赖后编译失效

• 日志中出现incrementalBuildHelper相关输出，对应Maven Compiler Plugin内置的增量编译校验逻辑。该逻辑会在正式调用javac前，对比源文件字节指纹、类路径上已存在的对应类的字节指纹，若判断两者无差异，会直接跳过javac实际执行流程，不会输出编译日志、不会生成类文件。
• 触发误判的核心原因出在BigDependencies这个shaded jar上：
  • 某次打包生成该公共jar时，错误将项目自身的已编译业务类（位于target/classes下的class文件）扫入了shaded包，导致增量校验逻辑误判所有待编译的源文件都已经处于“无变更、已编译”状态
  • 另一种可能是shaded jar体积超过2GB，触发了JDK JarFile读取逻辑的静默异常，javac加载类路径时无错误输出但直接中断流程
• Eclipse环境下编译正常的原因是：Eclipse使用内置JDT编译器，不调用Maven的增量校验逻辑，不受上述误判影响

• 临时快速验证：直接执行带强制参数的Maven命令，绕过增量校验逻辑，验证问题是否消失
  mvn clean test -Dmaven.compiler.useIncrementalCompilation=false
  若执行后能正常调用javac生成编译产物，即可确认是增量逻辑误判导致的问题
• 长期配置修复：在项目的pom.xml中，对maven-compiler-plugin的配置块增加固定参数，永久关闭有缺陷的增量校验：

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
      <useIncrementalCompilation>false</useIncrementalCompilation>
    </configuration>
  </plugin>
  

  该配置会强制编译器每次全量执行javac逻辑，不会因指纹匹配问题跳过编译流程
• 根源修复shaded jar包的问题：
  • 执行jar tf BigDependencies-0.0.1-SNAPSHOT.jar查看包内结构，搜索是否存在与项目源码同路径的class文件（如项目包名为com.bell.biz，则检查包内是否存在com/bell/biz路径下的class文件），若存在说明打包时错误混入了业务编译产物
  • 调整maven-shade-plugin的打包配置，确保打包范围仅包含第三方依赖，不扫描项目自身的target/classes、测试源码输出目录
  • 若shaded jar体积超过2GB，升级maven-shade-plugin到3.5以上版本，开启大文件Jar支持，避免Jar读取时的静默失败

之前尝试强制配置**/*.java源码包含规则没有效果，是因为问题本身就不在源码识别环节——编译器已经正确识别到了47个待编译源文件，只是在调用javac之前，被增量校验逻辑拦截跳过了实际编译流程，和源码匹配规则没有任何关系。

内容的提问来源于stack exchange，提问作者dreaded_snowman