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.
@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_jettyyou currently need to depend on//external:gwt_jettyAND//external:gwt_jetty-ioAND//external:gwt_jetty-utilbecause 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 = 1which 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.