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)
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 ajava_plugin
inandroid_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.