Add an annotation processor classpath to bloop

[pkolaczk]

Somehow I can't make Dagger2 work with bloop. Complains about missing generated classes like DaggerSystemComponent which should be generated for the following interface:

@Singleton
@Component(modules = SystemModule.class)
public interface SystemComponent
...

Looks like annotation-processing is bugs all the way down :(

My guess is that annotation-processing for the component class somehow happens after an attempt to compile the code referencing the generated class.

Any ideas what to look at?

[pkolaczk]

Looks like Bloop doesn't have a separate concept of annotation processor classpath. Is it correct?
When I put this into my gradle build file:

annotationProcessor(library("dagger_compiler"))

Dagger compiler is not present in the bloop.json classpath, hence the annotations are not processed :(

But when I replace that with:
compileOnly(library("dagger_compiler"))

The dagger compiler ends up on bloop's classpath and the annotation processor is executed.

However, a single classpath doesn't work for our project because some library versions are different and conflicting between the processorpath and classpath.

How much work would that be to separate these two things?
This is likely a show-stopper for us with Bloop. :(

[jvican]

However, a single classpath doesn't work for our project because some library versions are different and conflicting between the processorpath and classpath.

We're not planning on having different classpaths in the JSON configuration files at the moment. When we do, we will only add a runtime classpath and there are no plans to scale that to any other kind of classpath. A runtime classpath is widely used and deserves its place because the run task supported by bloop requires it. Other kinds of classpath such as processorpath require adding the notion of an annotation processor and that is not going to happen; bloop only cares about compiling, testing and running projects; anything else either needs to be simulated or supported in the host build tool.

However, I'd welcome a fix to support this in the logic of the build plugins. You can simulate two classpaths by creating two different build targets. One which is used first to process annotations and doesn't actually compile (let's call it A) and then another build target B, with the actual compile classpath, that depends on A and which will take anything generated previously by A and compile it.

There are other ways you can fix this issue. For example, consider either resolving the binary conflicts in your classpath manually or shading anything coming from Dagger.

[jvican]

After having a closer look, I've just realized that it's javac the one supporting the annotation processor. I initially thought it was the build tool you were using that was using its own custom processor engine.

It looks like in Gradle it's customary to use use a processor path that is independent of the compile path. https://discuss.gradle.org/t/regarding-the-annotation-processors-on-compile-classpath-warning-in-gradle-4-6/26144

In this case, as this would be supported by bloop itself, we could consider adding an optional processor path to the configuration file and then add the logic required to pass that in to the javac compiler.

I'm not going to work on this, so I'd love if you @pkolaczk can have a look at it and contribute this feature. One important aspect I'd like to know before getting a PR is what kind of logic we need to pass in the processor path to javac. Is javac supporting a special flag -processorpath? Do we need some special logic? What is that logic doing?

[pkolaczk]

bloop only cares about compiling, testing and running projects;

Annotation processing is part of compiling.

In this case, as this would be supported by bloop itself, we could consider adding an optional processor path to the configuration file and then add the logic required to pass that in to the javac compiler.

Yes, exactly this. Please note that this is also supported by Intellij IDEA as well. The default is to use the project classpath as the processor classpath, but the user can configure these classpaths separately if they wish.

Is javac supporting a special flag -processorpath?

Yes, it is.
See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/javac.html

Relevant options are:

• proc:[none,only]
• processor
• processorpath

Do we need some special logic? What is that logic doing?

I think the only thing you need is to pass a separate classpath to processorpath of javac. The annotation-generation logic already does work with bloop, because javac is doing that automatically, but without specifying processorpath it just uses the compile classpath.

[jvican]

Sounds good, then the fix for this should be quite straight-forward. We would only need to add the processor path to the javac options at the moment we export the build from the build tools. In this particular case, from Gradle. If there's more demand in the future, we can do the same in other build tools such as sbt or Maven.

I'm assigning you this ticket so that you can have a look at this whenever you can 😄. Fixing this issue would require a small change in the gradle bloop plugin logic under integrations/gradle-bloop/src/main/scala and then an integration test where we specify an annotation processor. You can inspire yourself from the tests defined under integrations/gradle-bloop/src/test/.