升级Wildfly及maven-compiler-plugin 3.6.0后注解生成源码编译失败求助

我之前在做 JBoss 到 Wildfly 版本升级时，也碰到过类似的 Cobertura 编译兼容性坑，结合你描述的情况，给你梳理几个针对性的排查和解决方向：

1. 优先确认 Cobertura 插件与新编译器的版本兼容性 #

你把 maven-compiler-plugin 从 3.1 升到 3.6.0 后本地解决了编译错误，但要注意：旧版本的 Cobertura Maven 插件（比如 2.7 及以下）对 Java 8 的语法支持存在缺陷，而 Wildfly 10.1 要求至少 Java 8 环境，这很可能是后续新问题的根源。

建议直接升级 cobertura-maven-plugin 到 3.0.0 及以上版本，同时在插件配置里明确指定 Java 版本，确保和编译器插件的 source/target 一致：

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>cobertura-maven-plugin</artifactId>
    <version>3.0.0</version>
    <configuration>
        <source>1.8</source>
        <target>1.8</target>
        <encoding>UTF-8</encoding>
        <!-- 可排除生成的元模型、测试类等不需要插装的类 -->
        <excludes>
            <exclude>**/*_.class</exclude>
            <exclude>**/test/**/*.class</exclude>
        </excludes>
    </configuration>
</plugin>

2. 本地解决但其他环境失效？检查环境一致性 #

如果问题仅在本地解决，CI/CD 或测试环境仍有异常，大概率是环境差异导致：

• 强制更新依赖缓存：在非本地环境执行 mvn clean install -U，强制拉取最新的插件和依赖包，避免旧缓存干扰。
• 核对 Java 版本：确认所有环境的 JDK 版本都是 Java 8（Wildfly 10.1 不兼容低于 8 的版本），部分 CI 环境可能默认用旧版 JDK，需要手动切换。
• 检查依赖范围：Wildfly 提供的容器级依赖（如 JPA、EJB 相关包）如果标记为 provided，Cobertura 插装时可能找不到字节码，可临时在 Cobertura 插件中追加这些依赖的 compile 范围配置，插装完成后再改回。

3. 针对后续新问题的通用排查思路 #

你提到升级后出现了新的“部分...”问题，结合这类场景的常见情况，可以从这几点入手：

• 字节码插装异常：如果报错涉及 Lambda、默认方法等 Java 8 新特性，说明旧版 Cobertura 不支持这些语法，升级插件是最直接的解决办法。
• 类找不到错误：检查模块中是否有升级后新增的依赖未正确引入，或者 Wildfly 替换了 JBoss 的某些构件（比如 Hibernate 版本从 3.x 升到 5.x），需要同步调整依赖的 groupId/artifactId。
• 排除特定类的插装：如果某些自动生成的类（如 Hibernate 元模型）或第三方类导致插装失败，直接在 Cobertura 配置的 <excludes> 中排除这些类即可。

如果能提供新问题的具体报错日志，还能更精准地定位问题~

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