hiltJavaCompile task loads deprecated annotation processors

[G00fY2]

We migrated our project to 100% KSP (Hilt 1.1.0-rc01, Room 2.6.0, Moshi 1.15.0) and removed all usages of kapt. Still we see a deprecation warning which should only be shown if the deprecated Moshi Code Gen Annotation Processor is being loaded into kapt/apt. See this build log from a minimal reproducible example project: https://github.com/G00fY2/HiltMoshiKaptWarning/actions/runs/6683702355/job/18160177116#step:5:44

I started a discussion in the Moshi project to make sure that this is not something wrong on Moshi's side: square/moshi#1752

@ZacSweers pointed out in that discussion that hiltJavaCompile task is capturing all KSP and kapt dependencies and passing them on to the JavaCompile task it creates. This causes the actually unused Code Gen Processor to print a deprecation warning.

Not sure what's the reason behind this. But would be nice if dagger/hilt would not load these classes and potentially mislead users.

[danysantiago]

That's right, the HiltGradlePlugin will configure the annotation processor classpath of the hiltJavaCompile to be a mirror of the kapt and ksp configurations. This is done for convenience such that if you have SPI Plugins or any other processor that does further code generation after Dagger, that it is done in the JavaCompile task where Dagger runs after Hilt codegen. Since moshi-kotlin-codegen ships both its KSP and JavaAP processors in the same artifacts, the JavaAP processor ends up being loaded for the JavaCompile task even though it will likely not run as no new annotations triggered by it will be present in the sources being compiled.

There are some options we can do here, but they all have some sort of pros-cons:

• The Hilt plugin could expose some flag to disable the automatic mirroring of the annotation classpath, that would mean we would also need to expose some configurations so users that do want SPI Plugins to run with full binding graph do so. This exposes the implementation detail that Dagger runs in a separate javac task when Hilt plugin is used, something that may or may not change in the future.

• Maybe Moshi could change the location where the message is reported such that only if it really needs to do processing then (i.e. in a round) it reports the warning and not when it is loaded. This is up to the Moshi authors to decide if it is possible and still maintains their desired migration to KSP goals.

• Ignore the warning and document reason. 😬

[mkubiczek]

How can I suppress this specific error when -Werror compiler flag is used?

[bcorso]

How can I suppress this specific error when -Werror compiler flag is used?

I think you'll have better luck asking on StackOverflow.