Figure correct usage of kt_jvm_* rules about mabel HOT 10 CLOSED

For what it's worth, you don't need this. You need to import jars/aars, not "kotlin classes" . These are also just jars. so java_import works. Maven-downloaded kotlin jars work just like java jars. It's all classes in zipfiles. :)

from mabel.

I noticed that too, but couldn't figure out why there is a kt_jvm_import. So, i left it there.
But, if the user does not provide the kt_* implemetations then java_import will be used.

from mabel.

Any idea in which cases I would want to use kt_jvm_?

from mabel.

So... don't take any cues from the kt_ rules. They have some rough edges, and are going to be rewritten by a Google team (or adapted). kt_jvm_import does some wrapping of things that Hassan thought would be important, but in my own maven integration work, I ended up reducing everything to java_import and aar_import, with no down-side.

I think there can be some value in some kt_* extra rules where there are features that aren't jvm focused (like, for instance, if one was to write a kotlinc plugin that wasn't an annotation processor expected to run in all Java Annotation Processing environments). But for the point of view of maven, gradle or ivy or maven itself doesn't special case these. It just provides jars, or ars, or other raw file artifacts as appropriate, and builds classpaths. Bazel does the same.

from mabel.

I even recommended against a kt_*_binary rules, because kotlin produces .jar content or .aar content suitable for android_binary, java_binary, and the native rules should probably be consumed by a cc_binary in the long-run. kotlin is the language, not the destination platform. There are platform-appropriate binary tools.

Imports are similar, unless there's a darned good reason (some metadata that's special and needs to be carried by a bazel aspect or something).

from mabel.

Ok, I have to walk this back. I had been led to understand that the ijar producer was substantially more kotlin aware than it actually is. There are plans in progress, but it's not there yet. The additional information is needed to avoid the more aggressive java ijar processor stripping method bodies (which shouldn't be stripped for inline functions).

from mabel.

thank you for reporting back. I've subscribed to square/bazel_maven_repository#43 to keep a tap if you figure something out.

from mabel.

Thanks. The whole problem goes away once bazelbuild/bazel#4549 happens. At that point, you can just use a java_import and be done with it. :/ So whatever I do will be a temporary workaround while waiting for that one.

from mabel.

Quick update - check the convo on the bazel bug - looks like the current plan of record is to use something similar to kt_jvm_import which doesn't propagate a separate compile_jar (ijar/abi_jar) for maven imports, since the benefits aren't terribly great. We could use kt_jvm_import, but that ends up creating an inter-workspace dependency on rules_kotlin. I'm going to make a similar import that does the right ijar thing, but doesn't try to propagate _KtInfo - just does javainfo without ijar. I'm making it a prerequisite for a 1.0 on my bazel/maven integration. Feel free to yoink that code once it's done (I'm putting it into its own file anyway)

from mabel.

#64

from mabel.