bazelbuild / java_tools Goto Github PK
View Code? Open in Web Editor NEWLicense: Apache License 2.0
License: Apache License 2.0
This issue follows the java_tools release process.
This is a backpatch release, because of the issue found in turbine bazelbuild/bazel#12605.
As such it is compiled from https://github.com/bazelbuild/bazel/commits/java_tools-release-10.5 branch.
This is a backpatch release.
It is compiled from https://github.com/bazelbuild/bazel/tree/java_tools-release-10.7 branch.
The branch was created from https://github.com/bazelbuild/bazel/tree/release-4.2.1-patches with additional cherry-pick bazelbuild/bazel@57672ac
This is a backpatch release.
As such it is compiled from https://github.com/bazelbuild/bazel/tree/release-4.1.0rc1 branch.
A new release for java_tools embedding javac9, javac10, javac12 is needed to be compatible with bazel 1.1 and later.
The 3 releases will have the same bazel commits as javac11-v6.0 (#17):
fe67c70cc43d910465dc415286118a81ad7eece4
fe67c70cc43d910465dc415286118a81ad7eece4
The releases can be cut on branch iirina:java-tools-cherry-pick-v6.1
and commit 52a920610cc997f979c9304c1df9250a2e80ecf8
. The build java_tools binaries pipeline is https://buildkite.com/bazel-trusted/java-tools-binaries-java/builds/123. These are the same commits and builds as in #17 (comment).
The new release:
@java_tools//:prebuilt_toolchain
which is using all the pre-built tools, including singlejar and ijar, even on remote execution. This toolchain should be used only when host and execution platform are the same, otherwise the binaries will not work on the execution platform.This issue follows the java_tools release process.
release candidates can be found under bazel_java_tools/release_candidates/javac11/v4.0
This new release contains loading @rules_java
statements inside the java_tools BUILD file.
This issue follows the java_tools release process.
release candidates can be found under bazel_java_tools/release_candidates/javac11/v3.0
Release procedure: https://github.com/bazelbuild/java_tools/blob/master/docs/release.md
Release to include fixed for bazelbuild/bazel#12605.
To include new version of error_prone and jacoco.
This issue follows the java_tools release process.
New release should be conducted, once the Error Prone PR is merged: [1].
BUILD still contains an entry for :Turbine
, pointing to java_tools/turbine_deploy.jar
, but that file no longer exists. Is the target unsupported?
This issue follows the java_tools release process.
The new release:
@java_tools//:prebuilt_toolchain
which is using all the pre-built tools, including singlejar and ijar, even on remote execution. This toolchain should be used only when host and execution platform are the same, otherwise the binaries will not work on the execution platform.This issue follows the java_tools release process.
release candidates can be found under bazel_java_tools/release_candidates/javac12/v2.0
Please add an AUTHORS file or similar that documents who holds the copyright for this project.
Releasing the first java tools version that contains javac 12.
This snippet was suggested for the bazel 3.5 release notes. It should be really be with the 14.0 release description.
# Java tools javac14 for Darwin
http_archive(
name = "remote_java_tools_darwin",
sha256 = "e20f002ceb3f3353d64c022e1f3400d8539ee56ffcfd4a6680d73d6a2cac938b",
urls = [
"https://mirror.bazel.build/bazel_java_tools/releases/javac14/v1.0/java_tools_javac14_darwin-v1.0.zip",
"https://github.com/bazelbuild/java_tools/releases/download/javac14-v1.0/java_tools_javac14_darwin-v1.0.zip",
],
)
# Zulu OpenJDK for Darwin
http_archive(
name = "openjdk14_darwin_archive",
build_file_content = "java_runtime(name = 'runtime', srcs = glob(['**']), visibility = ['//visibility:public'])",
sha256 = "088bd4d0890acc9f032b738283bf0f26b2a55c50b02d1c8a12c451d8ddf080dd",
strip_prefix = "zulu14.28.21-ca-jdk14.0.1-macosx_x64",
urls = ["https://mirror.bazel.build/cdn.azul.com/zulu/bin/zulu14.28.21-ca-jdk14.0.1-macosx_x64.tar.gz"],
)
And invoke the build with these parameters:
$ bazel build \
--java_toolchain=@remote_java_tools_darwin//:toolchain_jdk_14 \
--host_java_toolchain=@remote_java_tools_darwin//:toolchain_jdk_14 \
--javabase=@openjdk14_darwin_archive//:runtime \
--host_javabase=@openjdk14_darwin_archive//:runtime \
:foo
The release documentation should mention the toolchain flags. Right now it sounds like the only necessary step is to add the WORKSPACE stanzas, which is clearly not correct.
Changes:
This issue follows the java_tools release process.
This release splits java_tools into platform independent and prebuilt part. Toolchain definitions are moved from java_tools to bazel repository.
Created artifacts for rc1: https://buildkite.com/bazel-trusted/java-tools-binaries-java/builds/136
release candidates can be found under bazel_java_tools/release_candidates/javac11/v10.0 and bazel_java_tools/release_candidates/javac14/v2.0
Upgrading the java_tools version in bazel is happening in https://github.com/bazelbuild/bazel/tree/java_tools_release_javac11-v10_javac14-v2
This page is out of date: https://github.com/bazelbuild/java_tools/blob/master/docs/behind-the-release.md#manually-trying-out-java_tools-before-the-release-process
The //src:java_tools_javaX.zip
target doesn't exist anymore (I think it's been replaced by e.g. //src:java_tools_zip
).
It refers to --java_toolchain
, which doesn't work with bazel at head due to the switch to toolchain resolution.
A new release for java_tools embedding javac9 and javac10 is needed to be compatible with bazel 0.26 and later.
bazel 0.26 introduced jacocorunner
attribute on java_toolchain
.
Please modify the README.md so that it shows the exact command needed to check out the Java tools commit. For older releases I was able to just execute "git checkout SHA" because the commit was accessible from master or some other public branch. Recently, I've needed to do "git fetch http://github.com/bazelbuild/bazel.git SHA && git checkout SHA". It would have been helpful if that sequence were in the README.md file, so I could just paste it into my shell.
Thanks!
The new release:
@java_tools//:prebuilt_toolchain
which is using all the pre-built tools, including singlejar and ijar, even on remote execution. This toolchain should be used only when host and execution platform are the same, otherwise the binaries will not work on the execution platform.This issue follows the java_tools release process.
release candidates can be found under bazel_java_tools/release_candidates/javac10/v5.0
The release must contain bazelbuild/bazel#8490
This issue follows the instructions under java_tools release process.
RCs testing happens in bazelbuild/bazel#8182
All generated RCs are in https://pantheon.corp.google.com/storage/browser/bazel-mirror/bazel_java_tools/release_candidates/javac10/v3.0/
This PR implemented Java 16 toolchain: bazelbuild/bazel#13274.
The release notes state that, in order to override versions you can specify a github url:
"https://github.com/bazelbuild/java_tools/releases/download/javac11-8.0/java_tools_javac11_linux-v8.0.zip",
This does not resolve, and should be changed to https://github.com/bazelbuild/java_tools/releases/download/javac11_8.0/java_tools_javac11_linux-v8.0.zip
It looks like the previous releases were released with javac11-<version>
, but 8.0. with _
.
This issue follows the java_tools release process
With this PR, there is a goal to output compilation diagnostics through the BEP. Due to this, changes were introduced to the java_tools, namely to the BazelJavaBuilder
. For this, it is then required to release a new version of the java_tools.
Please correct me if the versioning system is not as follows.
The changes to the builder were introduced in b9a591e25d4325ae274661d69bd2fff46713e616.
Now, that bazelbuild/bazel#11871 is landed, there should be new release with JDK 15 toolchain support.
Ideally, Bazel would consume this new java_tools
per default, so that Bazel users could just select between supported toolchains: 8, 11, 14 and 15.
The new release:
@java_tools//:prebuilt_toolchain
which is using all the pre-built tools, including singlejar and ijar, even on remote execution. This toolchain should be used only when host and execution platform are the same, otherwise the binaries will not work on the execution platform.This issue follows the java_tools release process.
release candidates can be found under bazel_java_tools/release_candidates/javac9/v3.0
Created artifacts for rc1: https://buildkite.com/bazel-trusted/java-tools-binaries-java/builds/103
release candidates can be found under bazel_java_tools/release_candidates/javac11/v1.0
Upgrading the java_tools version in bazel is happening in bazelbuild/bazel#8302
Only x86_64 versions of java_tools exist. M1 macs are becoming the preferred machine for a lot of developers. Ideally there should be architecture specific releases.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.