-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
incompatible_remove_native_maven_jar #6799
Comments
This flag will break many projects in downstream, you can see the details at Please help them migrate (by filing issues and sending PRs and pinging the owners), thanks! |
Broken projects:
|
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. |
See bazelbuild/bazel#6799 for more details
merged: bazelbuild/rules_gwt#20 rules_k8s is breaking because of grpc, so marking it as fixed |
See bazelbuild/bazel#6799 for more details
See bazelbuild/bazel#6799 for more details
Since this flag is still not flipped in 0.22, 0.22 should still be its migration window. |
Going through the examples above, how would one specify a Maven server which requires authentication? The |
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 |
This removes our dependency on the deprecated native maven_jar rule: bazelbuild/bazel#6799 All changes except maven_dependencies.yaml are generated by the tool. At the same time, remove missing-jar-workaround.sh, which I haven't needed for some time. Change-Id: I22e15e340d98183156ef5942d0a11f4a759c6baa GitOrigin-RevId: 525db49
@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? |
@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 |
That would be 1.0.0rc1. https://releases.bazel.build/1.0.0/rc1/index.html |
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 |
Please see this document for a design proposal for a migration tool from |
Thanks! Cool to see progress on this! |
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 |
Baseline: 807ed23 Cherry picks: + db0e32c: build.sh: Fix bug in build script for RC release + 85e84f7: Set --incompatible_prohibit_aapt1 default to true. + 84eae2f: Let shellzelisk fallback to bazel-real if it's the requested version. + d5ae460: Fix a typo in bazel.sh Incompatible changes: - --incompatible_remap_main_repo is enabled by default. Therefore, both ways of addressing the main repository, by its name and by '@' are now considered referring to the same repository. see #7130 - --incompatible_disallow_dict_lookup_unhashable_keys is enabled by default #9184 - --incompatible_remove_native_maven_jar is now enabled by default and the flag removed. See #6799 - --incompatible_prohibit_aapt1 is enabled by default. See #10000 Important changes: - --incompatible_proto_output_v2: proto v2 for aquery proto output formats, which reduces the output size compared to v1. Note that the messages' ids in v2 are in uint64 instead of string like in v1. - Adds --incompatible_remove_enabled_toolchain_types. - Package loading now consistently fails if package loading had a glob evaluation that encountered a symlink cycle or symlink infinite expansion. Previously, such package loading with such glob evaluations would fail only in some cases. - The --disk_cache flag can now also be used together with the gRPC remote cache. - An action's discover inputs runtime metrics is now categorized as parse time on the CriticalPathComponent. - Make the formatting example more like to the written text by adding an initial description. - An action's discover inputs runtime metrics is now categorized as parse time on the CriticalPathComponent. - Bazel's Debian package and the binary installer now include an improved wrapper that understands `<WORKSPACE>/.bazelversion` files and the `$USE_BAZEL_VERSION` environment variable. This is similar to what Bazelisk offers (https://github.com/bazelbuild/bazelisk#how-does-bazelisk-know-whi ch-bazel-version-to-run-and-where-to-get-it-from), except that it works offline and integrates with apt-get. - We are planning to deprecate the runfiles manifest files, which aren't safe in the presence of whitespace, and also unnecessarily require local CPU when remote execution is used. This release adds --experimental_skip_runfiles_manifests to disable the generation of the input manifests (rule.manifest files) in most cases. Note that this flag has no effect on Windows by default or if --experimental_enable_runfiles is explicitly set to false. This release contains contributions from many people at Google, as well as aldersondrive, Benjamin Peterson, Bor Kae Hwang, David Ostrovsky, Jakob Buchgraber, Jin, John Millikin, Keith Smiley, Lauri Peltonen, nikola-sh, Peter Mounce, Tony Hsu.
This is no longer supported in bazel 2: bazelbuild/bazel#6799
Baseline: 807ed23 Cherry picks: + db0e32c: build.sh: Fix bug in build script for RC release + 85e84f7: Set --incompatible_prohibit_aapt1 default to true. + 84eae2f: Let shellzelisk fallback to bazel-real if it's the requested version. + d5ae460: Fix a typo in bazel.sh Incompatible changes: - --incompatible_remap_main_repo is enabled by default. Therefore, both ways of addressing the main repository, by its name and by '@' are now considered referring to the same repository. see bazelbuild#7130 - --incompatible_disallow_dict_lookup_unhashable_keys is enabled by default bazelbuild#9184 - --incompatible_remove_native_maven_jar is now enabled by default and the flag removed. See bazelbuild#6799 - --incompatible_prohibit_aapt1 is enabled by default. See bazelbuild#10000 Important changes: - --incompatible_proto_output_v2: proto v2 for aquery proto output formats, which reduces the output size compared to v1. Note that the messages' ids in v2 are in uint64 instead of string like in v1. - Adds --incompatible_remove_enabled_toolchain_types. - Package loading now consistently fails if package loading had a glob evaluation that encountered a symlink cycle or symlink infinite expansion. Previously, such package loading with such glob evaluations would fail only in some cases. - The --disk_cache flag can now also be used together with the gRPC remote cache. - An action's discover inputs runtime metrics is now categorized as parse time on the CriticalPathComponent. - Make the formatting example more like to the written text by adding an initial description. - An action's discover inputs runtime metrics is now categorized as parse time on the CriticalPathComponent. - Bazel's Debian package and the binary installer now include an improved wrapper that understands `<WORKSPACE>/.bazelversion` files and the `$USE_BAZEL_VERSION` environment variable. This is similar to what Bazelisk offers (https://github.com/bazelbuild/bazelisk#how-does-bazelisk-know-whi ch-bazel-version-to-run-and-where-to-get-it-from), except that it works offline and integrates with apt-get. - We are planning to deprecate the runfiles manifest files, which aren't safe in the presence of whitespace, and also unnecessarily require local CPU when remote execution is used. This release adds --experimental_skip_runfiles_manifests to disable the generation of the input manifests (rule.manifest files) in most cases. Note that this flag has no effect on Windows by default or if --experimental_enable_runfiles is explicitly set to false. This release contains contributions from many people at Google, as well as aldersondrive, Benjamin Peterson, Bor Kae Hwang, David Ostrovsky, Jakob Buchgraber, Jin, John Millikin, Keith Smiley, Lauri Peltonen, nikola-sh, Peter Mounce, Tony Hsu.
Bazel 2.0 removes `maven_jar` from native rules. In order for us to migrate to newer Bazel, `checkstyle_dependencies` need to be adapted according to guide in bazelbuild/bazel#6799
See bazelbuild/bazel#6799 for more details
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 torules_jvm_external
'smaven_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
or the convenience wrapper
instead.
Given a
WORKSPACE
file that looks like the following:It will need to look like this after updating:
Notably
licenses
attribute is mandatoryserver_urls
attribute is mandatory. If yourmaven_jar
rule did not specify a urlthen you should use the default server ("http://central.maven.org/maven2"). If your rule
did specify a url then keep using that one.
The text was updated successfully, but these errors were encountered: