Support for javac plugins.
Review Request #3839 — Created May 7, 2016 and submitted
|nhoward_tw, stuhood, zundel|
- Introduces a JavacPlugin target.
- Logic to compile plugins and generate their metadata file.
- Logic to compile with in-repo (or external, published) plugins
enabled. Allows two modes:
+ Targets can explicitly depend on a JavacPlugin, and that
plugin will be run when those targets are compiled. The plugin
will itself be compiled first if needed, naturally, so there's
no need to publish it first.
+ "Global" plugins can be specified via a JavacPluginSetup
subsystem. Any plugins configured there will be injected as deps
on every jvm target, and therefore compiled and used in all javac
compilations (except those of the plugin itself).
This allows you to apply "global" plugins (e.g., a linter)
without having to add dependencies everyhwere.
- Ensures that tools.jar is on the classpath when compiling
- Provides a hack to allow tests to pass without needing to set up
the JavacPluginSetup subsystem, since we have hundreds of tests
that use JvmTasks in various ways.
- Removes the truly gratuitous jvm backend dependency from
Note that the plugin API we support was introduced in Java 8, so
we have to temporarily exclude the example plugin from being compiled
in our tests, until we're entirely on Java 8 in our own CIs.
CI passes: http://jenkins.pantsbuild.org/job/pantsbuild/job/pants/branch/PR-3316/3/
What kinds of things would you do with this plugin? One thing that we've wanted is the ability to write a code generator in Java and have it plug into pants. Would this unlock that usecase?
I feel that the options namespace is already pretty overloaded ("jvm-platform", "jvm-distribution", "java", "javac-plugin-setup") and would love to see some consolidtion into useful groups.
Can these options live on the 'Java' subsystem instead?
IIRC, target_option already causes these to be parsed as addresses? Should be able to drop the re-parse below.
This comment should link to a github issue probably.
(It could maybe be fixed by transitively loading all subsystems required by the Targets in BuildFileAliases in TaskTestBase?)
Is this used somewhere in plugin loading? Would be good to add a bit more info on why/how it is used.
Is it worth extracting these three types (repeated in
compiler_plugin_types) into implementations of a simple
Get rid of JavacPluginSetup. Put its options directly on Java.
Revision 3 (+417 -107)
Submitted. Thanks Stu!