bazel-contrib / bazel-contrib/rules_jvm_external
Make exposing annotation processors easy
- 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
Assessment
This issue has not been assessed yet.