Add support for --incompatible_use_java_tools_beta_release flag for non disruptive way to bump java tool dependencies #11446
Labels
area-EngProd
Bazel CI, infrastructure, bootstrapping, release, and distribution tooling
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
untriaged
Comments
davido
added a commit
to davido/bazel
that referenced
this issue
May 19, 2020
Fixes bazelbuild#11446. Java tools are decoupled from Bazel distribution and downloaded from java_tools repository. If some of the tools is updated, the archive name is changed in Bazel and new Bazel release is conducted. If, however, new tool has some breaking changes, then the upgrade needs to be rolled back. To make user experience with upgrading tools less disruptive but still not unnecessary procrastinate releases of important Java tools like javac and Error Prone --incompatible_use_java_tools_beta_release is added and CI-job should be set up to check all downstream projects against upcoming java_tools release. Test Plan: 1. Upgrade Error Prone version to 2.3.4 Bazel that is known to have breaking changes and will break all Bazel users who rely on cross compilation use case. There are ongoing efforts to demote the offensive EP checks to warning severity instead of error, though: [1]. 2. Bump java_tools in beta_release archive to new java_tools distribution that includes Error Prone 2.3.4 3. Build rules_closure with --incompatible_use_java_tools_beta_release would fail with the known issue, because of unsatisfied dependency on javax.annotation: ERROR: /home/davido/projects/rules_closoure/java/io/bazel/rules/closure/BUILD:41:13: Building java/io/bazel/rules/closure/libtarjan.jar (1 source file) and running annotation processors (AutoAnnotationProcessor, AutoOneOfProcessor, AutoValueProcessor) failed (Exit 1) bazel-out/host/bin/java/io/bazel/rules/closure/_javac/tarjan/libtarjan_sourcegenfiles/io/bazel/rules/closure/AutoValue_Tarjan_Result.java:6: error: [ExtendsAutoValue] Do not extend an @AutoValue/@AutoOneOf class in non-generated code. final class AutoValue_Tarjan_Result<V> extends Tarjan.Result<V> { ^ (see https://errorprone.info/bugpattern/ExtendsAutoValue) See also upstream issue with in depth explanation what is going on there: [2] 4. Build rules_closure without the incompatible option: all is fine. That would mean, that all broken downstream projects would have enough time to adapt their build tool chains for upgraded dependencies in java_tools distribution. [1] google/error-prone#1619 [2] bazelbuild/rules_closure#483 Change-Id: I352297a8d0d86cecf30821c132c7871383e49b50
aiuto
added
area-EngProd
davido
added a commit
to davido/bazel
that referenced
this issue
May 21, 2020
Fixes bazelbuild#11446. Java tools are decoupled from Bazel distribution and downloaded from java_tools repository. If some of the tools is updated, the archive name is changed in Bazel and new Bazel release is conducted. If, however, new tool has some breaking changes, then the upgrade needs to be rolled back. To make user experience with upgrading tools less disruptive but still not unnecessary procrastinate releases of important Java tools like javac and Error Prone --incompatible_use_java_tools_beta_release is added and CI-job should be set up to check all downstream projects against upcoming java_tools release. Test Plan: 1. Upgrade Error Prone version to 2.3.4 Bazel that is known to have breaking changes and will break all Bazel users who rely on cross compilation use case. There are ongoing efforts to demote the offensive EP checks to warning severity instead of error, though: [1]. 2. Bump java_tools in beta_release archive to new java_tools distribution that includes Error Prone 2.3.4 3. Build rules_closure with --incompatible_use_java_tools_beta_release would fail with the known issue, because of unsatisfied dependency on javax.annotation: ERROR: /home/davido/projects/rules_closoure/java/io/bazel/rules/closure/BUILD:41:13: Building java/io/bazel/rules/closure/libtarjan.jar (1 source file) and running annotation processors (AutoAnnotationProcessor, AutoOneOfProcessor, AutoValueProcessor) failed (Exit 1) bazel-out/host/bin/java/io/bazel/rules/closure/_javac/tarjan/libtarjan_sourcegenfiles/io/bazel/rules/closure/AutoValue_Tarjan_Result.java:6: error: [ExtendsAutoValue] Do not extend an @AutoValue/@AutoOneOf class in non-generated code. final class AutoValue_Tarjan_Result<V> extends Tarjan.Result<V> { ^ (see https://errorprone.info/bugpattern/ExtendsAutoValue) See also upstream issue with in depth explanation what is going on there: [2] 4. Build rules_closure without the incompatible option: all is fine. That would mean, that all broken downstream projects would have enough time to adapt their build tool chains for upgraded dependencies in java_tools distribution. [1] google/error-prone#1619 [2] bazelbuild/rules_closure#483 Change-Id: I352297a8d0d86cecf30821c132c7871383e49b50
davido
added a commit
to davido/bazel
that referenced
this issue
May 21, 2020
Fixes bazelbuild#11446. Java tools are decoupled from Bazel distribution and downloaded from java_tools repository. If some of the tools is updated, the archive name is changed in Bazel and new Bazel release is conducted. If, however, new tool has some breaking changes, then the upgrade needs to be rolled back. To make user experience with upgrading tools less disruptive but still not unnecessary procrastinate releases of important Java tools like javac and Error Prone --incompatible_use_java_tools_beta_release is added and CI-job should be set up to check all downstream projects against upcoming java_tools release. Test Plan: 1. Upgrade Error Prone version to 2.3.4 Bazel that is known to have breaking changes and will break all Bazel users who rely on cross compilation use case. There are ongoing efforts to demote the offensive EP checks to warning severity instead of error, though: [1]. 2. Bump java_tools in beta_release archive to new java_tools distribution that includes Error Prone 2.3.4 3. Build rules_closure with --incompatible_use_java_tools_beta_release would fail with the known issue, because of unsatisfied dependency on javax.annotation: ERROR: /home/davido/projects/rules_closoure/java/io/bazel/rules/closure/BUILD:41:13: Building java/io/bazel/rules/closure/libtarjan.jar (1 source file) and running annotation processors (AutoAnnotationProcessor, AutoOneOfProcessor, AutoValueProcessor) failed (Exit 1) bazel-out/host/bin/java/io/bazel/rules/closure/_javac/tarjan/libtarjan_sourcegenfiles/io/bazel/rules/closure/AutoValue_Tarjan_Result.java:6: error: [ExtendsAutoValue] Do not extend an @AutoValue/@AutoOneOf class in non-generated code. final class AutoValue_Tarjan_Result<V> extends Tarjan.Result<V> { ^ (see https://errorprone.info/bugpattern/ExtendsAutoValue) See also upstream issue with in depth explanation what is going on there: [2] 4. Build rules_closure without the incompatible option: all is fine. That would mean, that all broken downstream projects would have enough time to adapt their build tool chains for upgraded dependencies in java_tools distribution. [1] google/error-prone#1619 [2] bazelbuild/rules_closure#483 Change-Id: I352297a8d0d86cecf30821c132c7871383e49b50
philwo
added
the
team-OSS
|
I don't think we'll do this, the complexity of doing migrations between java_tools releases like that isn't worth the gain. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Java tools are decoupled from Bazel distribution and downloaded from java_tools repository.
If some of the tools is updated, the archive name is changed in Bazel and new Bazel release is conducted. If, however, new tool has some breaking changes, then the upgrade needs to be rolled back.
To make user experience with upgrading tools less disruptive but still not unnecessary procrastinate releases of important Java tools like
javacand Error Prone--incompatible_use_java_tools_beta_releaseshould be added and CI-job should be set up to check all downstream projects against upcomingjava_toolsrelease.The text was updated successfully, but these errors were encountered: