-
Notifications
You must be signed in to change notification settings - Fork 213
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
Kotlin 1.3 support #159
Comments
I'm using mildly modified versions of these rules with 1.3 successfully.
Please do add the error in question. That'll help with diagnosis.
…On Thu, 8 Nov 2018 at 11:46 Markus Padourek ***@***.***> wrote:
I tried to use these rules using the latest kotlin 1.3 release by manually
setting kotlin repositories(compiler release={... }) It downloaded the
compiler fine but then complained about a missing dependency. I am on my
mobile now so unfortunately do not have the error message but will update
once on my desktop tomorrow. Just wanted to report this in the meantime.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#159>, or mute the
thread
<https://github.com/notifications/unsubscribe-auth/AAUN4qnOLrr2hd8F9G-rH_3UoX7A2kZmks5utIotgaJpZM4YVXGC>
.
|
Back on my machine now. The error is:
The BUILD file is:
And yeah if I switch back to the default kotlin compiler the application runs as expected. Maybe also relevant I am running on the latest bazel rc: Edit: |
Can you post (or exerpt) your WORKSPACE file as well? Bazel itself shouldn't be an issue, as this is nearly certainly a matter of how the toolchain is specified, and what ends up imported where. |
@cgruber at its simplest it is
|
I'm also stuck at the same point using Kotlin 1.3, with the same compiler release (basically same workspace as above), but with a different error:
Seems that there is a mismatch between the third-party dependencies of the rules and those of the project sources. |
After commenting out:
I get the same error as @pierreis above. There seem to be a few other people who have run into this issue: https://discuss.kotlinlang.org/t/org-jetbrains-annotations-notnull-problem-with-android-build/629 & JakeWharton/timber#295 but have not been able to fix it with |
Ah the error even happens for a hello world example. And I am seeing that So adding I seem ot be getting to the next error:
So the build actually works and I am getting a runtime error. |
@cgruber Getting a bit off point here (happy to open up a separate issue) but just trying to use https://github.com/square/moshi with the kotlin-codegen plugin. But for some reason the generated does not seem to be picked up by the resulting jar. Do you know by any chance how to get this to work? Is there something missing in bazel for it to include the generated code? |
@Globegitter - sadly no. You'd have to open an issue on square's moshi project and explore it there. |
@Globegitter, before I try it myself, did you try updating the dependencies in third_party/jvm/workspace.bzl based on the dependency YAML file? |
@pierreis not all of them, in fact I only tried to update |
@pierreis you can actually see my progress here: https://github.com/Globegitter/rules_kotlin/tree/exports |
KT-27895 (the annotations bug) as been fixed in Kotlin 1.3.10. |
@pierreis @cgruber using the patched repo from https://github.com/Globegitter/rules_kotlin/tree/exports with 1.3.10 as well as manually adding Not sure why that is necessary but at least it is running. |
@Globegitter awesome, thanks. |
Yeah - thanks @Globegitter. No love from maintainers yet. I believe there are plans for more focus/ownership on the kotlin side, but it's all informal discussions I'm having at this point, with no firm commitments yet. To be fair, some people were out for personal reasons, and are only getting back recently. Hopefully we'll see more action soon. |
@Globegitter thanks for your effort! To be able to compile sourcecode with 1.3 features, I had to add the version in toolchains.bzl.
Without this, I got an error:
|
I will at least update my fork. I'm hoping thomas and co can come on-stream soon and start taking maintenance pulls here, even while they look at re-doing the whole ruleset. |
Sorry, I hvaen't updated my fork, as there are quite a few other issues going on, not hte least of which is that the 1.3 kotlinc package doesn't inclue kotlin-runtime (which is now in kotlin-stdlib) and so the rule needs some special handling in order to handle that case. I have prototyped it a bit, but in our square internal fork. Once I settle on an actual working version, I'll throw it into my fork. It may not matter, insofar as the #174 suggests the google-internal rules may be open-sourced soon, but not knowing the timelines yet on availability, I'll probably still do it as a stop-gap, so folks can use the legacy rules with 1.3 until the harmonized super-awesome rules are in place. |
Hi @cgruber we're hoping to upgrade to Kotlin 1.3 -- are you still planning on updating your fork with a working version? If so would be greatly appreciated. |
Hey - sorry, I'm just working on our internal fork now, for 1.3 support. I can back-port what I do there to my repo, in the near-term. But also, Globegitter has a 1.3-based fork here: https://github.com/Globegitter/rules_kotlin/tree/exports I haven't tried it, but it should work. Regardless, I'm deep in the structure of the present rules, making them 1.3 workable, and so once I have that fixed internally, I"ll externalize those changes. Hopefully I'll have something external by next week. Hoping for something working internally in the next couple of days. |
@cgruber thanks so much I appreciate your update and work. Looking forward to seeing what you create. |
We've been using this fork, with this patch applied https://github.com/loreto/rules_kotlin/pull/1 |
Seems I'm able to download the artifact with the following change:
It is an incomplete build graph though yielding the error @Globegitter mentioned. Looking at the maven repo it looks like the |
Again, internally I have this fixed, and am under pretty intense deadline pressure. I'll try to push something out, but it's very likely that it won't support both 1.2 and 1.3 kotlinc. (That is, you can use kotlinc 1.3 in 1.2 language mode, but it is frustrating to make the change agnostic to the kotlinc version. |
I note with interest that the @Globegitter rules are failing for me when using bazel 0.25.2 with:
and the "official" bazel rules don't yet support 1.3. Any chance of the merged ruleset being released in the near future? |
I'm actively (like, at this literal moment) working on making my fork work. I'm happy to port any of the changes back to the legacy branch, though I'll need a sponsor on the google side for reviews and merging. |
Hi everyone, The timelines for the new Kotlin rules have slipped. Due to these delays in releasing we’ve decided to accept @cgruber’s fork as a stop-gap measure to support the community. We’re actively working with him to get this merged, and will be open to receiving pull requests for features and bug fixes until the Google rules are released. Thank you for your patience through this process, and your support for an awesome Kotlin + Bazel experience! |
Pressure's on, but I'll be looking at starting this process next week. |
So... this week apparently. :) Sorry for the slip. |
Fixed by #205 |
Is there an ETA for a new release which will includes this fix? |
Major enhancement is Kotlin 1.3 support, see bazelbuild/rules_kotlin#159 Change-Id: I5dd9c34b0e5469537c81718403ff58d987050095 GitOrigin-RevId: 9a983166b62c9310ac9aef3338050f1590018913
Exposes a toolchain function (define_kt_toolchain) to allow the specification of non-default chains. Sets the default chain to 1.3.21. Removes the now-removed use-coroutines flag, which is permanently on. This also sets the compiler to permit use of experimental APIs. This is needed for people migrating from the older experimental coroutines to the new ones, during migration. This should be configurable, but for now it's just set. Also fixes up some tests and does some minor cleaning. Fixes bazelbuild#159 > Note: This no longer supports using pre-1.3 kotlinc distributions. You can make a toolchain that sets the language and api levels to 1.3, but you must use a 1.3+ kotlinc.
Exposes a toolchain function (define_kt_toolchain) to allow the specification of non-default chains. Sets the default chain to 1.3.21. Removes the now-removed use-coroutines flag, which is permanently on. This also sets the compiler to permit use of experimental APIs. This is needed for people migrating from the older experimental coroutines to the new ones, during migration. This should be configurable, but for now it's just set. Also fixes up some tests and does some minor cleaning. Fixes bazelbuild/rules_kotlin#159 > Note: This no longer supports using pre-1.3 kotlinc distributions. You can make a toolchain that sets the language and api levels to 1.3, but you must use a 1.3+ kotlinc.
I tried to use these rules using the latest kotlin 1.3 release by manually setting
kotlin repositories(compiler release={... })
It downloaded the compiler fine but then complained about a missing dependency. I am on my mobile now so unfortunately do not have the error message but will update once on my desktop tomorrow. Just wanted to report this in the meantime.The text was updated successfully, but these errors were encountered: