Make exposing annotation processors easy

[shs96c]

Right now, all dependencies are downloaded into @maven workspace. This is great, until we need to include an annotation processor as a java_plugin: then we need to break out of the workspace and define our own rule --- it's no longer possible for someone to expect all third party dependencies to be in the same namespace, which opens the door for mistakes to be made in build files by people not aware that they need to include a different rule from a different workspace.

bazel-deps is similarly focused on "just downloading bits from maven" as rules_jvm_external but provides an processorClasses property, which exports the annotation processor as expected without impacting the UI exposed to people writing build files.

bazel_maven_repository solves the same problem less elegantly by allowing people to specify build file fragments.

The ideal solution would be a field on maven.artifact that allowed a list of annotation processor classes to listed (mirroring bazel-deps approach).

[jin]

I addressed this previously in https://github.com/bazelbuild/rules_jvm_external/issues/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?

[jin]

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.

[jin]

@shs96c do you still have the patch for this?

[shs96c]

I need to rewrite it --- the codebase has moved on enough that my patch is super stale.

On Thu, 29 Aug 2019 at 20:20, Jin notifications@github.com wrote:

@shs96c https://github.com/shs96c do you still have the patch for this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bazelbuild/rules_jvm_external/issues/144?email_source=notifications&email_token=AAAG4ROSKXHLEN6IY4IGGYTQHAOP5A5CNFSM4HNCBG32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5PRKWA#issuecomment-526325080, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAG4RLBTRU42DTDZA5O3WLQHAOP5ANCNFSM4HNCBG3Q .

[jin]

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

[cgruber]

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.

[menny]

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.