You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jun 14, 2024. It is now read-only.
@ekuefler, you may recall bazelbuild/bazel#1952 where we had a discussion about best practices for defining Maven dependencies.
With your approval, I would like to volunteer my time to migrate this project to what seems to be the emerging consensus. That would entail modifying gwt/gwt.bzl to use java_import_external.
Faster downloads, redundant URLs, connection retries, exponential backoff, connection reset recovery, fast failover, auto-avoidance of low-bandwidth mirrors, captive portal avoidance, and compliance with policies of certain great firewalls. See: bazelbuild/bazel@ed7ced0
Shorter names. You can say deps = ["@com_google_guava"] instead of deps = ["@com_google_guava//jar"].
Dependency relationships are encoded into repositories. If you want //external:gwt_jetty you currently need to depend on //external:gwt_jetty AND //external:gwt_jetty-io AND //external:gwt_jetty-util because maven_jar didn't let you specify that jetty depended on those jars. With java_import_external, if you want jetty, you just depend on jetty.
Ability to set testonly = 1 which maven_jar doesn't do.
Ability to set licenses = ["notice"], etc. which maven_jar doesn't do.
Ability to define annotation processors. See Dagger example here.
If you find the technical merits of these developments compelling, let me know, and I'll move forward.
Side note: I have another cool repository rule I've developed called filegroup_external (source) which you may also find interesting. I'd love to hear your thoughts.
The text was updated successfully, but these errors were encountered:
Go for it! Glad to here there's growing consensus here and the new rules look pretty slick. I'm not overly happy with the current state of the GWT dependencies, so feel free to modify them however you think would make the most sense (and update instructions in the README accordingly).
Thanks for all your work figuring out best practices here.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@ekuefler, you may recall bazelbuild/bazel#1952 where we had a discussion about best practices for defining Maven dependencies.
With your approval, I would like to volunteer my time to migrate this project to what seems to be the emerging consensus. That would entail modifying gwt/gwt.bzl to use java_import_external.
List of Converted Projects
Benefits of Migration
Faster downloads, redundant URLs, connection retries, exponential backoff, connection reset recovery, fast failover, auto-avoidance of low-bandwidth mirrors, captive portal avoidance, and compliance with policies of certain great firewalls. See: bazelbuild/bazel@ed7ced0
Shorter names. You can say
deps = ["@com_google_guava"]
instead ofdeps = ["@com_google_guava//jar"]
.Dependency relationships are encoded into repositories. If you want
//external:gwt_jetty
you currently need to depend on//external:gwt_jetty
AND//external:gwt_jetty-io
AND//external:gwt_jetty-util
because maven_jar didn't let you specify that jetty depended on those jars. With java_import_external, if you want jetty, you just depend on jetty.Ability to set
testonly = 1
which maven_jar doesn't do.Ability to set
licenses = ["notice"]
, etc. which maven_jar doesn't do.Ability to define annotation processors. See Dagger example here.
If you find the technical merits of these developments compelling, let me know, and I'll move forward.
Side note: I have another cool repository rule I've developed called filegroup_external (source) which you may also find interesting. I'd love to hear your thoughts.
The text was updated successfully, but these errors were encountered: