bazel-contrib / bazel-contrib/rules_jvm_external

Make exposing annotation processors easy

Open
#144 7 comments 9 reactions 2 assignees Claimed by @shs96c View on GitHub
type: feature request
Dominant language
Java
Stars
373
Forks
301
Avg merge
7d 17h
Merged PRs (30d)
3

Description

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](https://github.com/johnynek/bazel-deps) is similarly focused on "just downloading bits from maven" as `rules_jvm_external` but provides an [processorClasses](https://github.com/johnynek/bazel-deps#annotation-processors-processorclasses) property, which exports the annotation processor as expected without impacting the UI exposed to people writing build files.

[bazel_maven_repository](https://github.com/square/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](https://github.com/bazelbuild/rules_jvm_external/blob/master/docs/api.md#mavenartifact) that allowed a list of annotation processor classes to listed (mirroring `bazel-deps` approach).

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.