bazel: incompatible_remove_native_maven_jar

The native maven_jar rule will no longer be available with this flag set to true.


(Update: managed by @jin as of July 12)

A migration tool will be provided to automatically convert maven_jar targets to rules_jvm_external’s maven_install rule, and modify BUILD files to use the new labels.

See https://docs.google.com/document/d/1CqxPv-TwvFWBHgtg7_QhVfck4vH4rnmCU_IuMdC7O2M/edit# for a design document of this migration tool.


Proposal by @dkelmer as of Nov 28, which is another valid migration solution that is done manually:

Use

load("@bazel_tools//tools/build_defs/repo:java.bzl", "java_import_external")

or the convenience wrapper

load("@bazel_tools//tools/build_defs/repo:jvm.bzl", "jvm_maven_import_external")

instead.

Given a WORKSPACE file that looks like the following:

maven_jar(
    name = "truth",
    artifact = "com.google.truth:truth:0.30",
    sha1 = "9d591b5a66eda81f0b88cf1c748ab8853d99b18b",
)

It will need to look like this after updating:

load("@bazel_tools//tools/build_defs/repo:jvm.bzl", "jvm_maven_import_external")
jvm_maven_import_external(
    name = "truth",
    artifact = "com.google.truth:truth:0.30",
    artifact_sha256 = "59721f0805e223d84b90677887d9ff567dc534d7c502ca903c0c2b17f05c116a",
    server_urls = ["http://central.maven.org/maven2"],
    licenses = ["notice"],  # Apache 2.0
)

Notably

  • the licenses attribute is mandatory
  • sha1 is no longer supported, only sha256 is
  • the server_urls attribute is mandatory. If your maven_jar rule did not specify a url then you should use the default server (“http://central.maven.org/maven2”). If your rule did specify a url then keep using that one.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 33 (25 by maintainers)

Commits related to this issue

Most upvoted comments

merged: https://github.com/bazelbuild/rules_gwt/pull/20 merged: https://github.com/bazelbuild/rules_appengine/pull/96 merged: https://critique.corp.google.com/#review/229611659&tab=a (intellij, SOT is internal) merged: https://github.com/grpc/grpc-java/pull/5327 merged: https://github.com/googlesamples/android-testing/pull/245 filed issue: https://github.com/bazelbuild/BUILD_file_generator/issues/48 (they use bazel-deps and updating requires updating their custom scripts so I’ll leave that to them)

rules_k8s is breaking because of grpc, so marking it as fixed

The automated migration tool is available here: https://github.com/bazelbuild/rules_jvm_external/tree/master/migration

If you don’t wish to migrate to rules_jvm_external, please follow the alternative instructions to manually migrate to jvm_maven_import_external.

@JLLeitschuh I do not have the answer for you at the moment. I am following up with folks from the security team with your question on issuing a CVE, the next steps, and also to verify our remediation approaches (#9237, #9235, https://github.com/bazelbuild/bazel/commit/b065b1318641db2e75b12ca6a29c89d9265f3389, original sha1 issue ref: https://github.com/bazelbuild/bazel/issues/8880)

@dapengzhang0 There is not an automated tool. You need to independently fetch the jars and calculate the sha256. One thing you can do is omit the artifact_sha256 attribute and run bazel fetch. Bazel will then tell you what sha it expected for each jar.

Broken projects: