bazelbuild / bazelbuild/rules_java

Unable to use stamp information in `java_binary`'s MANIFEST.MF

Open
#266 1 comment 0 reactions 0 assignees View on GitHub
P2
Dominant language
Starlark
Stars
103
Forks
102
PR merge metrics
No merged PRs in 30d

Description

As far as I can tell, it currently isn't possible to use the output from `--workspace_status_command` in `java_*` rules. Specifically, it seems like a fairly common use-case (and coincidentally, what I'm currently trying to do 😉) would be to include some form of build information (revision / build date / whatever) in the `MANIFEST.MF` of a `.jar` file.

**Expected behaviour**: able to `--stamp` a `java_binary` with custom variables
**Actual behaviour**: unable to pass through any custom variables to `deploy_manifest_lines`
**Steps to reproduce**:

As a fairly trivial reproduction:

```starlark
# .bazelrc
common --stamp --workspace_status_command=/usr/bin/true --embed_label="Hello"
```

```starlark
# BUILD.bazel
java_binary(name = "test", ..., deploy_manifest_lines = [ "Custom-Label: {{BUILD_EMBED_LABEL}}" ])
```

Running `bazel build :test_deploy.jar && unzip -p bazel-bin/test_deploy.jar META-INF/MANIFEST.MF` outputs:

```
...
Custom-Label: {{BUILD_EMBED_LABEL}}
...
```

rather than the desired:
```
...
Custom-Label: Hello
...
```

**Extra information**

I'm not 100% sure if this has changed in newer versions of `rules_java` (having a quick glance at the source, it seemed not?) but at least as of v7.x the attribute for `deploy_manifest_lines` only accepts a `list` of strings, and states:

> The contents of this attribute are not subject to "Make variable" substitution.

It seems like there are maybe two related problems*, one is specific to `rules_java` and the other is a more general Bazel thing:

1. `java_binary` only accepts fixed strings for `deploy_manifest_lines`
2. Bazel does not provide _convenient_ access to workspace status vars in macros or custom rules.

From what I've seen in some other places (e.g. `rules_oci`) there's no good solution to (2), so the pattern seems to be to allow providing a single file to use, and then having a command that generates that file by also reading from the `bazel-out/stable-status.txt` and `bazel-out/volatile-status.txt` files, e.g.

```starlark
# BUILD.bazel
java_manifest(name = "manifest", lines = {"Custom-Label": "{{BUILD_EMBED_LABEL}}")
java_binary(name = "test", ..., deploy_manifest_lines = ":manifest")
```

`*` I imagine some people will argue this is a feature, but it doesn't feel like it from here!

If it's possible to do it without generating an intermediate file, that would be even better, but I suspect that won't be the case (at least without some major work to Bazel itself...)!

Contributor guide

Open the contributing guide

Research direction

Start with the java_binary deploy_manifest_lines attribute and reproduce the issue using the .bazelrc and BUILD.bazel examples. Inspect how workspace status is exposed through bazel-out/stable-status.txt and bazel-out/volatile-status.txt, then define a supported way for custom values to reach META-INF/MANIFEST.MF and verify the result in the generated test_deploy.jar.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.