Checker Framework plugin broken by de92b00.

[Pyroxin]

Hello! I'm trying to use the Lombok plugin with the Checker Framework plugin and I've discovered an apparent incompatibility that was introduced by de92b00 (the fix for issue #1301).

Background

The Checker Framework plugin depends on sources processed with delombok because the Checker Framework runs an annotation processor. The plugin adds Checker Framework to the build options and then sets the compileJava task to depend on delombok when the Freefair Lombok plugin is present. de92b00 makes the delombok task dependent on compileJava which leads to a dependency cycle in the task graph when trying to apply the Checker Framework plugin, resulting in the following failure message:

FAILURE: Build failed with an exception.

* What went wrong:
Circular dependency between the following tasks:
:lib:compileJava
\--- :lib:delombok
     \--- :lib:compileJava (*)

(*) - details omitted (listed previously)

nb. The lib project is part of the default sample project created by Gradle 8.13 when generating a Java library project using gradle init. The config is available here.

While I ran into this issue with the Checker Framework plugin, the issue can be recreated by adding the following to a build script:

tasks {
    // ... 
    named<JavaCompile>("compileJava") {
        dependsOn("delombok")
    }
    // ...
}

Rolling back to version 8.12.1 resolves the issue. Rolling forward to 8.12.2 or later reintroduces the build failure.

Potential Solutions

I see two main possible solutions:

1. Create a new compile task that only runs annotation processors to generate sources (i.e., a new JavaCompile task that passes -proc:only to the compiler), have delombok depend on that, and then set the compileJava task to depend on delombok. This is a solution I attempted to apply through a pre-compiled script plugin and through a build script directly but Gradle fails with an error about task dependency removal not being allowed.
2. Revert de92b00. I am concerned that adding more customizations to the Java build will sideline other users with use cases we can't reasonably foresee. While the change in de92b00 is convenient, it disrupts existing use cases. The safest and most flexible course of action is to revert de92b00 and instruct users with special source set inclusion needs to configure their builds themselves.

I prefer option 2 because it maximizes user flexibility; the current situation requires users in my position to maintain a modified version of the Lombok plugin or not use it at all while reverting de92b00 requires the submitter of #1301 to add a single line to their build script. Can this commit be reverted?

Thank you for your time.

(Incidentally, I'm also running into a conflict between Lombok and Error Prone that isn't related to the Lombok plugin as far as I can tell. Reverting de92b00 would also help me resolve that problem since I'm going to probably need to adjust task dependencies.)

[Frisch12]

Hey @Pyroxin,

I am very sorry that your problem has not yet been addressed. Give me some time to investigate your problem in detail. Can you possibly provide me with a Gradle project that reproduces this error?

Thank you in advance, Dennis

[Frisch12]

@Pyroxin it would be a great help if you can provide a small test project, as I'm not able to reproduce the issue with the shared resources yet.

[Pyroxin]

Thanks for the reply and apologies for the delay in my reply! I've created a minimal project here that reproduces the issue. I have also re-confirmed that the issue is still present. The README also contains some extra details that may help with troubleshooting.

[tjakopan]

Facing the same issue. I'm trying to use checkerframework plugin with this plugin.

[larsgrefer]

We have two conflicting use cases here with no clear solution:

1. In #1301 the user-written source code refers to code, that an annotation processor generates. De-lomboking this does not work without the generated sources, so delombok needs to depend on the compileJava task to generate the sources.
2. The checker Framework wants to run on de-lomboked sources, because it can't handle running together with lombok in the same javac pass.

Configuring both requirements simultaneously in the same compileJava task forms a circular dependency, as described above.

To break this cycle, we would need either two delombok passes or two javac passes.

The Checker Framework documentation states:

Therefore, you must run the Checker Framework in a postpass after the javac that runs Lombok has completed.

The Checker Framework Gradle plugin could do exactly that: Don't configure the Checker Framework to run in the main compileJava task, but create a second JavaCompile task that can safely depend on the delombok task.