incompatible_remove_native_maven_jar

[dkelmer]

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.

[meteorcloudy]

This flag will break many projects in downstream, you can see the details at
https://buildkite.com/bazel/bazel-at-release-plus-incompatible-flags/builds/48

Please help them migrate (by filing issues and sending PRs and pinging the owners), thanks!

[dkelmer]

Broken projects:

• android testing: https://github.com/googlesamples/android-testing
• BUILD_file_generator: https://github.com/bazelbuild/BUILD_file_generator
• intellij/CLion plugin: https://github.com/bazelbuild/intellij
• migration tooling: https://github.com/bazelbuild/migration-tooling (the project is deprecated and read only)
• rules_appengine: https://github.com/bazelbuild/rules_appengine
• rules_docker: https://github.com/bazelbuild/rules_docker
• rules_gwt: https://github.com/bazelbuild/rules_gwt
• rules_k8s: https://github.com/bazelbuild/rules_k8s (breaking because of dependency on grpc)
• rules_scala: https://github.com/bazelbuild/rules_scala
• grpc: https://github.com/grpc/grpc-java/blob/master/repositories.bzl (not on CI, but rules_k8s depends on them)

[meisterT]

cc @vladmos this is a classical example where buildifier could help with fixing the projects, because it's a mostly mechanical change

Danna: it would be great if we could prioritize this migration, because the maven rules are one of the two "users" of the java.desktop module which contributes to 1/3 of the embedded JDK size.

[dkelmer]

merged: bazelbuild/rules_gwt#20
merged: bazelbuild/rules_appengine#96
merged: https://critique.corp.google.com/#review/229611659&tab=a (intellij, SOT is internal)
merged: grpc/grpc-java#5327
merged: android/testing-samples#245
filed issue: bazelbuild/BUILD_file_generator#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

[meteorcloudy]

Since this flag is still not flipped in 0.22, 0.22 should still be its migration window.

[guw]

Going through the examples above, how would one specify a Maven server which requires authentication?

The native.maven_rule has a server attribute which takes a name of a server. Authentication credentials for such a server would be specified in ~/.m2/settings.xml. The location of the settings file was configurable with native.maven_server rule.

[dkelmer]

Thanks for bringing this up, the native maven_jar rule will not be deprecated before there is support for authentication with a local maven server

[dapengzhang0]

@dkelmer How did you get the sha256 values? As the default server ("http://central.maven.org/maven2") only provides sh1. Is there an automated tool that can get sha256 values for a lot of dependent maven jars?

[dkelmer]

@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.

[jin]

That would be 1.0.0rc1. https://releases.bazel.build/1.0.0/rc1/index.html

[JLLeitschuh]

Hey @jin unless Google plans to make an official disclosure for this, the CVE to use is the generic one for SHA-1 https://nvd.nist.gov/vuln/detail/CVE-2005-4900

[jin]

Please see this document for a design proposal for a migration tool from maven_jar to rules_jvm_external.

[JLLeitschuh]

Thanks! Cool to see progress on this!

[jin]

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.