-
-
Notifications
You must be signed in to change notification settings - Fork 287
Open
Description
Minimal reproduction here: https://github.com/contagnas/singlejar_referenceconf_repro
Analysis from that:
- rules_scala’s no‑src fast path calls singlejar directly and always passes --warn_duplicate_resources along with the --resources list. This is the only path taken when srcs is empty, so the jar is built entirely by singlejar.
https://github.com/bazelbuild/rules_scala/blob/v7.1.6/scala/private/phases/phase_compile.bzl#L266-L277 - singlejar pre‑registers a special combiner for reference.conf, so that multiple reference.conf entries can be concatenated.
https://github.com/bazelbuild/bazel/blob/9.0.0/src/tools/singlejar/singlejar_main.cc#L30-L45 - when singlejar processes --resources, it treats any resource whose name already exists in known_members_ as a duplicate when --warn_duplicate_resources is set, and returns early without adding it.
https://github.com/bazelbuild/bazel/blob/9.0.0/src/tools/singlejar/output_jar.cc#L984-L1005 - Because reference.conf is pre‑registered, the first and only reference.conf passed via --resources is considered a duplicate and dropped. That leaves the output jar without the resource, and explains why the repro only happens for reference.conf and only on the no‑src fast path.
I think the proper fix for this is probably something in singlejar, but a workaround here to omit the --warn_duplicate_resources flag when a reference.conf file is present might be appropriate to avoid this
Metadata
Metadata
Assignees
Labels
No labels