Update the rules so that they are compliant with the intelij aspects conventions for ide plugins.

[hsyed]

The Skylark aspect rules aspect expect a java_provider set in the target output or a language specific attr -- Scala rules have the scala attribute. The kotlin_compile rule already adds a "kt" attribute -- although it is not compliant -- it misses "outputs" and other attributes. I think the future for this kind of thing is to use the java_provider and the language attributes is a interim solution.

see the aspect impl here

I don't know if the aspect logic is capable of processing macros -- but I doubt It.

kotlin_binary, kotlin_library and kotlin_test should probably be turned into rules.

[hsyed]

from @brendandouglas

As far as updating the kotlin rules so that the aspect recognizes them, the easiest way to do that would be to expose java_common.provider (https://docs.bazel.build/versions/master/skylark/lib/java_common.html).

Then our aspect will automatically recognize that these are 'java-like' targets, and will grab the necessary data (header/class/source jars, etc.).

@brendandouglas does the skylark logic process/consider macros ?

[hsyed]

@pcj Do you have time to do this one ? I'll likely end up breaking backwards compatibility.

[hsyed]

@pcj The hack I put in to get the aspects working in intellij while working is very limiting, also not having resources , data, exports, runtime_jars etc is also limiting so I have started a rewrite of the skylark logic. I have got kotlin_library and kotlin_binary as self contained rules (with exports, runtime_jars and resources).

I am going to reach out on bazel-discuss and propose official support for Kotlin from the Bazel Developers -- are you ok migrating this repo to the bazelbuild org ?

[hsyed]

@pcj I have completely reworked the rules in my fork. The focused has been on replacing the macros with first class rules and to start aligning the rules with the feature-set found in the java rules. I have hidden away some aspects like the compiler switches and I have removed the android macros. I am in the process of getting the repository accepted into bazelbuild/rules_kotlin.

The android support and compiler switches etc will gradually be reintroduced using appropriate metaphors (toolchains, providers, etc) -- a lot of this will come out of community design.

We have a discussion going on bazel-discuss about the proposal to move my fork to bazelbuild.. It would be great if you could look at my work and if you could join our effort in designing and evolving the rules. Assuming you have no reservations the work should be accepted fairly soon.

[hsyed]

implemented in my fork, out of scope for these rules.