rules_jvm_external
jjudd opened this issue · 4 comments
https://github.com/bazelbuild/rules_jvm_external seems to be the rules the Bazel team is pushing for jvm third party libraries and maven support.
Do we want to investigate it, and if it meets our needs, replace our forked Bazel deps with it?
👍 from me.
Do Scala JARs need special handing around java_import? Some Kotlin JARs don't work with java_import, which bazelbuild/rules_jvm_external#69 is addressing.
Scala JARs need special handling if and only if they have macros.
The ScalaInfo provider has a macro boolean attribute to indicate this. If there are macros, the Scala compiler is given the runtime classpath rather than the compiler classpath.
Any non-macro Scala JARs need no special handling, and can use the rest of the JVM rules/providers as-is. (There might be corner cases...not sure. In any case, treating it as a macro JAR will work.)
IIRC @jjudd, Lucid had a global handwritten whitelist of macro external dependencies, and when iterating through list_dependencies(), either call java_import_external or scala_import_external depending on whether they exist in the macro list. This has the virtue of reusing java rules as much possible, while handling the macros as an exception.
(This method is also why I believe that the API of bazel-deps should be list_dependencies() bazeltools/bazel-deps#153.)
@pauldraper thanks for the explanation. In bazelbuild/rules_jvm_external#69, jars will not be imported by java_import, but by a simple Starlark jvm_import.bzl that places the imported jar into JavaInfo.output_jar and JavaInfo.compile_jar. There's no disambiguation between Java, Scala or Kotlin jars, and should bypass the ijar issue discussed in bazelbuild/bazel#632