improve inference of scala-ness

[johnynek]

A heuristic that is probably very good if that if your artifact id ends with _a.b for some integers a and b and you depend on a version of scala-library version a.b.x, we can assume you are scala.

If we get it wrong (before java-sandwich in bazel ships) you can just explicitly add the dependency and label the language as java.

This should help with macros, since we assume any scala dependency could have macros.

[kamalmarhubi]

I believe the last bits of java sandwich are either landed or landing soon. What would change here? And would fixing this remove the need for #5?

[johnynek]

No. they would not help much. Scala jars may have macros, so bazel's ijar tool cannot be run on them safely. That won't change with all of java sandwich.

Note, java can already depend on scala using the current scala rules, but we still need to import the jars differently in the java and scala case.

In fact, there is now a scala_import rule that @ittaiz wrote which we would like to use in this project. That will help things a bit from a tooling standpoint (e.g. intellij plugin support), but not really from a standpoint of needing to distinguish scala from java.

[gkossakowski]

i think now that rules_scala has support for scala_import we should emit it always for both direct and transitive scala dependencies. I agree that looking at whether there's a direct dependency on scala library is a good heuristic. This would provide a much better experience for scala users of bazel-deps: you don't need to define your transitive dependencies explicitly solely to mark them as scala.

[libsamek]

I have another example of where can this heuristic be improved:

  org.scalamock:
    # this needs to be explicitly defined to be generated as scala_import and not java_library
    # since it uses macros, which doesn't work ti java_library
    scalamock-core:
      lang: scala
      version: "3.6.0"
    scalamock-scalatest-support:
      lang: scala
      version: "3.6.0"

scala-mock-scalatest-support has dependency scalamock-core (which uses macro) and must be defined as scala_import. If scalamock-core is not explicitly defined, java_library is used, which causes problems with macros. This should be improved to use scala_import, even though it is not explicitly defined as dependency.

If only scalamock-scalatest-support is defined as dependency, this causes build problems:

...
Exception in thread "main" java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file org/scalamock/clazz/MockImpl$
...