| commit | ad6d4d7f839687548776c7f5f79704bdb6af7d0e | [log] [tgz] |
|---|---|---|
| author | Googler <ilist@google.com> | Wed Aug 16 07:38:06 2023 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Wed Aug 16 07:40:46 2023 -0700 |
| tree | 0a12f3c29c44ecb0bed03c3b325194185f6ae611 | |
| parent | 7c4bf7fff28d81dd9aa0326994fdd050af372bc9 [diff] |
Merge java_binary/java_test with launcher into a single rule Add `//tools/build_defs/java:launcher_label_alias` target that reads native java_launcher/host_java_launcher flag. The target will be later replaced with label_flag. The implementation returns no providers, when flag is unset. Later on this can be solved, by implementing a "sentinel" launcher, that's used when the flag is unset. `label_flag` acts as a proper `alias`. Use `//tools/build_defs/java:launcher` as default value for `launcher` field in Java rules, remove computed default. This replicates the previous behavior. First the value of `launcher` attribute is used if set. Then the value of the flag is used. If the flag is also not set, the default is used. Handle `launcher = None` in the macro part. attr.label has a weird behaviour: If set to None, the default value is used (and that is a flag). Drop additional flavours of java_binary/java_tests. They are not needed. Update mocks for unit and integration tests There are further cleanup of the code possible, however probably better to do them in a separate change. PiperOrigin-RevId: 557481404 Change-Id: I581e790aad8187b02d161ee6c0d76108fa5e8261
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
