Make exposing annotation processors easy about rules_jvm_external HOT 7 OPEN

I addressed this previously in #38 with the rationale that this rule is single purposed on resolving and fetching Maven artifacts, and adding Java annotation processing features will diverge from that and increase the API surface. However, placing this data in the artifact spec helper makes sense - I think the helper didn't exist when I made that comment in #38.

cc @aehlig thoughts?

from rules_jvm_external.

Let's move forward with this. Dagger, Auto-* and other annotation processors are core to many builds, and the API to integrate with them using the spec helper approach is a nice and simple design.

from rules_jvm_external.

@shs96c do you still have the patch for this?

from rules_jvm_external.

from rules_jvm_external.

Assigning you to this issue as well, but no hurry :)

from rules_jvm_external.

The issue with automatically specifying these directly is that some processors have separate annotations artifacts which would be attached with an exported_plugins, and some (like dagger) have the API that configures (e.g. the imported dep) be (a) the thing that should export the plugins, but also (b) consumed by the plugin implementation (e.g. dagger-compiler). This creates a cycle and it's a pain in the ass to work through.

The naive dagger bazel-workspace equivalent to the artifact relationship creates a cycle where com.google.dagger:dagger depends exports the plugin is defined by com.google.dagger:dagger-compiler which depends on com.google.dagger:dagger. I had to (in my build_snippets) introduce an indirection and THEN, account for that indirection within the package BUILD file for com.google.dagger, by having all local references point at the private copy.

It's possible that the indirection can be generalized so it works for auto-value as well, but thinking of a really good way to express that is what's delayed me from adding something like plugins = [plugin("processor.Class", "processor:artifact")] (or whatever) to bazel_maven_repository.

I'd love to see it though. It's definitely sub-optimal to have to use build_snippets for this.

from rules_jvm_external.

With mabel, I've went with downloading the jar during the rules generation phase. mabel will then look at the Processor and extract the classes. Then I create java_plugin for each of the processors and a library that exports all of them together.

I don't know if this method will work for rules_jvm_external but it was good there.

from rules_jvm_external.