-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Android extensions support #145
Comments
Yes a PR would be very welcome. Could you outline what the extensions do -- I am not an android developer (yet). I assume we need to enable Kotlin compiler plugins for this. We need a working kitchen sink style Android example in this repository to work on this. @jin is looking into an idiomatic example. We'd need a plugin abstraction in the builder. I have a huge pr with a custom compiler plugin so I will add a extension point something along the lines of: abstract class PluginAdapter(private val jar: String, private val id: String) {
// return null if not enabled.
open fun contributeArguments(context: CompilationTaskContext, task: JvmCompilationTask): List<String>? = null
open fun postProcess(context: CompilationTaskContext, task: JvmCompilationTask, t: Throwable?){}
} Then we need a way of enabling and disabling plugins from the rules. Hopefully these plugins don't require any configuration in which case we could just pass a |
The Android extensions add syntactic sugar to access views. In Android, the UI is defined in a layout file which is written in XML. When you want to use a view from the code, you assign it an id. Then, you would use findViewById with your id to access your view from the code. This adds a lot of boilerplate. The Android extensions add a series of properties that allows you to access them without having to write all the findViewById calls. The way you use them in Gradle is adding an additional plugin to the build.gradle file. I've taken a quick look at the code of the extensions and it seems there's a bit of code generation however, it doesn't seem to be using kapt so I would assume that it is, in fact, a compiler plug in but I'm not really certain about it. Regarding your abstraction layer, I like it, I would refine it a little bit. Something like this abstract class PluginAdapter(private val jar: String, private val id: String) {
abstract fun isEnabled(context: CompilationTaskContext, task: JvmCompilationTask): Boolean
abstract fun contributeArguments(context: CompilationTaskContext, task: JvmCompilationTask): List<String>
abstract fun postProcess(context: CompilationTaskContext, task: JvmCompilationTask, throwable: Throwable?)
} Adding the isEnabled function, you can remove the nullability on the list in contributeArguments which, I think, makes the code nicer. Since you say your PR is huge, perhaps, I can quickly write the abstract class and make a PR for it that you can merge independently. That way, the size of your PR would get reduced. |
In addition, android extension is gradle plugin. This plugin auto generate classes. Can we use gradle plugin in bazel? How to resolve this problem? apply plugin: 'kotlin-android-extensions' Realm is gradle plugin, such as android-extension. I need to use this or i can use google's room. This library use annotation process. Gradle have annotation process, that generate code. Such as I use annotationProcessor for my gradle project, but how use annotation process in bazel? |
@Kadanza, you shouldn't have any problems using room since these rules, as far as I know, already allow the use of kapt. In the case of Realm, I'm not even sure if it should be tackle in this project or in the general Android rules. However, if it is ok, I'd like to keep this issue focused on getting support for Android extensions. |
I would not recommend working on getting synthetic extensions working since they are experimental unless it comes for free with compiler plugin support. A better endevour would be Parcelize which is built on the same mechanisms but will be made available as a stable feature in the 1.3.x timeframe. |
Yes it is a compiler plugin. I have found it in the compiler distribution. The plugin comes with a runtime component. The runtime component would need to be dexed, I don't think it needs to go into the The plugin will probably need to be given the paths of the android resources to process I think you will need to add a new kotlin builder flag for it. Along with a builder flag the rule needs to get the resource path attribute, I don’t think this should be added to the attributes of
The heuristic for 2:
@jin what do you think ? Since the plugin generates classes (or source files and then classes) it should probably be run in the
Returning null is quite idiomatic in jetbrains code. It allows for elegant chaining patterns. Alternatively you could just return an empty list as well which might be most appropriate here. |
@JakeWharton This is the plugin we are talking about. In the tutorial I see a |
Elaborate on which part? In order to have those imports generated you must enable their experimental nature. If you scroll down you'll see the Parcelable section: https://kotlinlang.org/docs/tutorials/android-plugin.html#parcelable. This is also currently experimental but they are going to become stable in Kotlin 1.3.x. |
@JakeWharton, I have just looked at the official Kotlin documentation and it seems that the Android extensions that allows the synthetic imports for the views are production ready. However, even if these features were experimental, why should that prevent Bazel support for them? I don't find any compelling argument to state that because a certain feature is experimental, it shouldn't be widely supported by build systems other than Gradle. Anyway, if I misunderstood your point, please, let me know. |
The entire feature is experimental, not just parts of it.
Did you read what you quoted? I said if it comes for free then it's fine. |
Don't take me wrong. I just want to know where you are coming from. I think the documentation should say explicitly that the whole feature is experimental. The fact that there is an experimental mode within the feature itself is a bit weird, don't you think? Perhaps, I don't understand the reasoning behind it. But, what I really want to understand is why only experimental features that are easy to implement should be ported to Bazel. It would be great if you could clarify this for me. |
Both of the features of the Gradle plugin are entirely experimental which you must opt in to. We are in the process of making Parcelize enabled by default. I said nothing about "easy". I said focus on the feature that is becoming stable and rather than the one that isn't. |
It's too long wait then Kotlin android extension become stable. We can use only findViewById. |
I'm not familiar with Android Extensions at all, but after reading through the conversation so far, I've gathered the following:
|
It is a compiler plugin, a build plugin, and part of the IDE plugin. It is
not an annotation processor.
…On Mon, Sep 17, 2018, 4:59 AM Jingwen ***@***.***> wrote:
I'm not familiar with Android Extensions at all, but after reading through
the conversation so far, I've gathered the following:
1. It's a Kotlin compiler plugin.
2. It's an annotation processor.
3. It's not clear whether this should be scoped within rules_kotlin or
rules_android.
4. It should probably reuse the java_plugin
<https://docs.bazel.build/versions/master/be/java.html#java_plugin>
architecture. @hsyed <https://github.com/hsyed> the 3rd plan for a
kt_compiler_plugin sounds like the best solution to me.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#145 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEEEc1whJ24aHRxf08xnZiG1wpPsq4Gks5ub2RfgaJpZM4Wp9bw>
.
|
@jin I am in nyc for an interview. I notice you are based in NY. I am staying in the meatpackers district. I’m free all day thursday if you would like to meet up and discuss the rules. |
@hsyed Unfortunately I'm not in NYC this week. |
Hey, I've seen that when a new Android project using Kotlin is created with Android Studio, these extensions are used by default. Is it still an experimental feature, or are there plans to support it in Bazel? |
We're actively working on this, at Square, just as an update. We may have a poor implementation initially, with it hard-coded (with some detection or signaling). In the long-run, I'd like to see a kt_plugin() but we may have a variant of the android extensions supported before we get so far as that. |
I'm curious how hard will it be to also integrate newish I haven't checked how tightly this feature is tied to AGP, I guess if it relies on some command-line tool, it can be reused. |
Don't know, it would require some investigation. It's really frustrating how much the kotlin features end up leaning on gradle, but mostly they are extricable. |
Early and poor implementation is now available here: inez@8309825 |
We'll re-structure @inez' PR against the cgruber repo and replay it here. |
hi @inez , I have seen that you have been able to solve the error in the rules_kotlin of the Kotlin Android support. We are working on a project in which we have that problem when making the compilation. Please, could you tell me how you have solved it? Have you made the changes you made locally? If so, could you help me solve my problem. Best regards |
have this issue resolved because its still comming in legacy_1.4? |
Hi guys, would we have any update here? |
hey, did you happen to get viewbinding work in bazel? |
Related #522 |
Duplicate of #231 and the conversation has evolved somewhat off-line. Closing this, but the issue will continue in another bug, as we figure out what's working and isn't. |
I have a Gradle project that I want to move to Bazel. I've managed to make everything works but these rules don't seem to provide a way to integrate Android extensions, which the project I mentioned makes heavy use of. I was wondering whether the support already exists or whether it is in the roadmap.
I was also wondering if this is not in the roadmap, would a PR implementing this be welcomed?
Thanks in advance for your response.
The text was updated successfully, but these errors were encountered: