Test java coverage with java_tools released and built at head. #8361
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
iirina
force-pushed
the
java-coverage-test-with-toolchain
branch
from
7e907cf to
d7f9370
Compare
hlopko
suggested changes
May 17, 2019
| ], | ||
| ) | ||
| http_archive( | ||
| name = "openjdk10_darwin_archive", |
There was a problem hiding this comment.
All of this will be a burden to keep in sync with reality. What about extracting these to a bzl file that will be used from WORKSPACE and from the test?
There was a problem hiding this comment.
Defining the archives in only one place and re-using it sound good, but I'm not sure how to use a bzl file. I can only think of defining a rule that creates all these repositories and load it from the WORKSPACE file, is that what you were thinking as well?
There was a problem hiding this comment.
I ended up using a regular text file to store the http_archives for all JDKs. I also used this file in bazel_java_test. Note that we don't need all these JDKs in bazel's WORKSPACE file (only the Linux version) so I won't add more remote repos in the WORKSPACE file.
hlopko
approved these changes
May 20, 2019
irengrig
pushed a commit
to irengrig/bazel
that referenced
this pull request
Jun 18, 2019
This follows the same setup in bazel_java_test.sh for configuring the java_toolchain and javabase. Closes bazelbuild#8361. PiperOrigin-RevId: 249057124
copybara-service bot
pushed a commit
that referenced
this pull request
May 31, 2023
Context: #18373 Currently the definitions of java tools, remote JDKs, and Java toolchains are duplicated in both Bazel sources and rules_java, and they go out of sync quite often. By default, the default toolchains shipped with the Bazel binary uses the one in Bazel sources except when Bzlmod is enabled. bazelbuild/rules_java#110 syncs java toolchain related files from Bazel sources to rules_java and this PR removes most of the definitions in Bazel source and uses rules_java as the source of truth. Significant changes in this PR: - Removed all java tools definitions from distdir_deps.bzl - Removed all remote JDK definitions from distdir_deps.bzl except the ones for to be embedded within Bazel binary. - Changed `jdk.WORKSPACE.tmpl` to load java tools and JDKs from rules_java as WORKSPACE suffix. - Removed the `jdk_http_archives` hack for some shell tests. That dates back to #8361, I don't think it's needed since we have the WORKSPACE suffix by default. - When building Bazel with Bazel, we were using the java toolchains shipped in `@bazel_tools` of the Bazel binary, now we use the java toolchains from the `rules_java` defined in distdir_deps.bzl. This enables us to build Bazel itself with the latest java toolchain, therefore can detect issues earlier. - Removed `_for_testing` suffixes for the shared repo hack for Bazel CI since the java tools and remote JDKs versions we load to build Bazel are the same as the ones shipped in the Bazel binary we built (via `jdk.WORKSPACE.tmpl`) and used in the integration tests. They all come from the rules_java version in distdir_deps.bzl. - Removed the `test_WORKSPACE_files` hack for `workspace_resolved_test.sh`. - Mocked rules_java in some integration tests to avoid needing to download it or its transitive dependencies. Breaking changes: - Loading `.bzl` files under `@bazel_tools//tools/jdk` in WORKSPACE now requires you to define `rules_java` in advance, the `rules_java` definition in WORKSPACE suffix cannot guarantee `@rules_java` exist because it's appended after the content of the user WORKSPACE file. Closes #18423. RELNOTES[INC]: Loading `.bzl` files under `@bazel_tools//tools/jdk` in WORKSPACE now requires `rules_java` to be defined in advance. PiperOrigin-RevId: 536682532 Change-Id: Ia7475bfe134729ab1592b0ef0a31d28eb839b5ac
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This follows the same setup in bazel_java_test.sh for configuring the java_toolchain and javabase.