rules_kotlin: Android rules not working properly with exported Java plugins

Following Dagger’s recommended Hilt integration, when using this android_library target with the following Java class, the code generation runs fine:

android_library(
    name = "app",
    srcs = ["SampleApplication.java"],
    manifest = "AndroidManifest.xml",
    deps = [
        ":res",
        "//third_party/dagger/hilt:hilt-android",
    ],
)
package fr.enoent.android.sample;

import android.app.Application;
import dagger.hilt.android.HiltAndroidApp;

@HiltAndroidApp(Application.class)
public class SampleApplication extends Sample_BurgApplication {
}

The exact same set-up with a kt_android_library, however, doesn’t end up calling the plugins exported by //third_party/dagger/hilt:hilt-android at all. Even when only passing the same Java file to kt_android_library - the compilation fails because the generated superclass isn’t generated.

From there, I tried passing the plugins explicitly to the kt_android_library’s plugins attribute. With a Java file, they don’t seem to run at all either (maybe expected?). With a Kotlin file, some seem to run, but either not all or not in the correct order, I’m really not familiar enough with annotation processors to understand what’s going on there - one of the Hilt plugins fails because the superclass hasn’t been generated.

I’m not sure how much of that is working as intended, but it’s a strong behavioural difference from the native android_library (and I believe kt_jvm_library as well?).

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Reactions: 3
  • Comments: 20 (5 by maintainers)

Commits related to this issue

Most upvoted comments

This is a long-standing issue, it seems, related to how the rules collect plugin info - we special case java_library, and don’t special case android_library. This is wrong, but it’s been wrong for years. We should (and will) roll a fix, but it pre-exists, and we won’t block 1.5 for it.

That said, it’s awful and we should roll a fix. I’ll try to get it in before release, but no promises. However, it should be in 1.6, now that we understand it.

@geaden Sorry I edited the code I posted to keep things at their simplest and made a typo there - the code in my initial comment is indeed incorrect, but what I have locally is correct. I’ll give that fix a try asap.

I’ve come upon the same issue when using dagger_android_rules. These also wrap a java_plugin in android_library, but unlike with Hilt there is only one processor class.

As @geaden wrote plugins.bzl quite clearly doesn’t handle android_library rules. I was able to reproduce the issue here and make the tests pass again with the proposed fix. Not sure why Hilt is still failing, it might be a separate issue.