Refactor handling of API generation in JavaPluginInfoProvider

Instead of keeping two copies of state for the API-generating and
non-API-generating cases, create a 'JavaPluginInfo' abstraction to contain all
state for each case, and then keep two copies in the top-level
JavaPluginInfoProvider provider.

This will make it easier and less error-prone to add additional state to the
provider.

PiperOrigin-RevId: 204151605

1 files changed, 1 insertions, 10 deletions

diff --git a/src/main/java/com/google/devtools/build/lib/rules/android/DataBinding.java b/src/main/java/com/google/devtools/build/lib/rules/android/DataBinding.java
index c589342614..6adbb0cf00 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/android/DataBinding.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/android/DataBinding.java
@@ -156,16 +156,7 @@ public final class DataBinding {
             ruleContext.getPrerequisite(
                 DATABINDING_ANNOTATION_PROCESSOR_ATTR, RuleConfiguredTarget.Mode.HOST));
 
-    for (String name : plugin.getProcessorClasses()) {
-      // For header compilation (see JavaHeaderCompileAction):
-      attributes.addApiGeneratingProcessorName(name);
-      // For full compilation:
-      attributes.addProcessorName(name);
-    }
-    // For header compilation (see JavaHeaderCompileAction):
-    attributes.addApiGeneratingProcessorPath(plugin.getProcessorClasspath());
-    // For full compilation:
-    attributes.addProcessorPath(plugin.getProcessorClasspath());
+    attributes.addPlugin(plugin);
     attributes.addAdditionalOutputs(getMetadataOutputs(ruleContext));
   }