Inconsistency on scala_library resources handling when `srcs` is empty vs not

[wisechengyi]

Problem

On master:

$ bazel build test:ScalaLibResources
...
$ unzip -Z1 bazel-bin/test/ScalaLibResources.jar
META-INF/
META-INF/MANIFEST.MF
scalarules/
scalarules/test/
scalarules/test/ScalaLibResources$.class
scalarules/test/ScalaLibResources.class
scalarules/test/byes
scalarules/test/hellos
test/
test/data/
test/data/some.txt

Now, remove the srcs related to the scala_library:

diff --git a/test/BUILD b/test/BUILD
index facd88b..fd6c1f5 100644
--- a/test/BUILD
+++ b/test/BUILD
@@ -217,7 +217,7 @@ java_library(
 
 scala_library(
     name = "ScalaLibResources",
-    srcs = ["src/main/scala/scalarules/test/ScalaLibResources.scala"],
     resources = [
         "//test/data:some.txt",
         "//test/src/main/resources/scalarules/test:byes",

Now we have:

$ bazel build test:ScalaLibResources
...
$ unzip -Z1 bazel-bin/test/ScalaLibResources.jar
test/data/some.txt
scalarules/test/byes
scalarules/test/hellos
META-INF/MANIFEST.MF

Note that the directories such as

test/
test/data/

are no longer in the jar.

This causes downstream test that relies on getClass.getResource("/test/data/") to fail unexpectedly, as sometimes we need a scala_library with empty srcs as placeholders.

Initial Diagnosis

With

bazel aquery test:ScalaLibResources

The one with srcs will have more actions such as Scalac, which means sense, but at the same time, it also alters the behavior on how the resources will be available for downstream consumers, which is unexpected.

[simuons]

Hi @wisechengyi, thanks for reporting this.

The issue is that there is a check if sources are provided and depending on the presence of sources jars are build differently. _build_nosrc_jar is used when no sources are provided. Otherwise resources are copied to jar by ScalacWorker

Definitely this should be unified, unfortunately I have no knowledge why _build_nosrc_jar was introduced.

[ittaiz]

1. I think we had the same or very similar issues when migrating to bazel but I don't remember how we solved them :(
2. I also don't remember why nosrc_jar was introduced (I think some git blame can dig it up) but if I'd have to guess I'd say it was because we don't want to pay the cost of scalacworker. Maybe we can use the bazel zipper which is cheaper than scalacworker but might still be consistent?