Embed a default java_toolchain macro into java_tools. #8613
Conversation
iirina
force-pushed
the
embed-default-java-toolchain
branch
from
24fbe05
to
7a3448b
Compare
| fi | ||
| cat >WORKSPACE <<EOF | ||
| load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") | ||
| http_archive( |
There was a problem hiding this comment.
Will local_repository work instead of http_archive?
There was a problem hiding this comment.
local_repository only works if we unzip the archive first, which means additional setup and complexity in the tests. My intention was also to test the archive in the same way it is used by Bazel and Java users.
|
|
||
| # override the javac in the JDK. | ||
| "--patch-module=java.compiler=$(location :java_compiler_jar)", | ||
| "--patch-module=jdk.compiler=$(location :jdk_compiler_jar)", |
There was a problem hiding this comment.
I'm actually confused here, so I'll ask :) Is it true that this relative label keeps referencing @bazel_tools//tools/jdk:java_compiler_jar even when we call the macro from a random package //foo/bar? Or it assumed that the //foo/bar package has those labels around?
| "jacocorunner": ":jacoco_coverage_runner_filegroup" | ||
| } | ||
|
|
||
| def default_java_toolchain(name, **kwargs): |
There was a problem hiding this comment.
Alternative is to make all of these default values of attributes on java_toolchain, effectively making java_toolchain itself serve the purpose of the macro. Is that viable?
|
Closing this for now, please ping/reopen if you're intending to work on this. |
There are several benefits of using a macro:
@java_tools//:toolchainand@java_tools//:toolchain_jdkX)soruce_versionandtarget_version).@bazel_tools//tools/jdk:default_java_toolchain.bzlwill be deprecated and removed in favor of@java_tools//:java_tools/java_tools_defs.This change also adds test cases for building targets in the java_tools repository. Note that ijar and singlejar don't yet build on Windows (see #8614).