flasn4nt
/
grpc-java
mirror of https://github.com/grpc/grpc-java.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
grpc-java/WORKSPACE

48 lines
1.5 KiB
Python
Raw Normal View History

all: rename Bazel workspace to io_grpc_grpc_java Fixes #4095
2018-02-23 05:59:45 +08:00
workspace(name = "io_grpc_grpc_java")
build: Add Bazel java_grpc_library rule Bazel third party dependencies are specified in repositories.bzl which gives the consumer the ability to opt-out of any dependencies they use directly in their own project. Fixes #2756
2017-06-23 04:06:49 +08:00
bazel: Support maven_install maven_install is strongly superior to previous forms of grabbing dependencies from Maven as it computes the appropriate versions to use from the full transitive dependencies of all libraries used by an application. It also has much less boilerplate and includes dependencies with generated targets. In the future we will drop the jvm_maven_import_external usages and require maven_install, at which point we can swap to using the `@maven' repository and no longer depend on compat_repositories. Fixes #5359
2019-12-19 06:51:08 +08:00
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "rules_jvm_external",
all: Update netty to 4.1.77.Final and netty_tcnative to 2.0.53.Final (#9027) all: Update netty to 4.1.77.Final and netty_tcnative to 2.0.53.Final Also switches to a non-release version of rules_jvm_external to allow Bazel build to work with artifact classifiers.
2022-06-25 01:47:27 +08:00
sha256 = "c21ce8b8c4ccac87c809c317def87644cdc3a9dd650c74f41698d761c95175f3",
strip_prefix = "rules_jvm_external-1498ac6ccd3ea9cdb84afed65aa257c57abf3e0a",
url = "https://github.com/bazelbuild/rules_jvm_external/archive/1498ac6ccd3ea9cdb84afed65aa257c57abf3e0a.zip",
bazel: Support maven_install maven_install is strongly superior to previous forms of grabbing dependencies from Maven as it computes the appropriate versions to use from the full transitive dependencies of all libraries used by an application. It also has much less boilerplate and includes dependencies with generated targets. In the future we will drop the jvm_maven_import_external usages and require maven_install, at which point we can swap to using the `@maven' repository and no longer depend on compat_repositories. Fixes #5359
2019-12-19 06:51:08 +08:00
)
load("@rules_jvm_external//:defs.bzl", "maven_install")
load("//:repositories.bzl", "IO_GRPC_GRPC_JAVA_ARTIFACTS")
load("//:repositories.bzl", "IO_GRPC_GRPC_JAVA_OVERRIDE_TARGETS")
Upgrade Protobuf to 3.19.1 and Guava to 30.1.1 Protobuf uses Guava 30.1.1, so I upgrade it at the same time. It also caused an update to rules_jvm_external and reworking the Bazel build. Protobuf no longer requires bind() so they were dropped. Although Protobuf's protobuf_deps() brings in rules_jvm_external, and so we don't need to define it ourselves, it seems better to define it directly and not depend on transitive deps since we use it directly. Protobuf now has support for maven_install() by exposing PROTOBUF_MAVEN_ARTIFACTS, which required reorganizing the WORKSPACE to use maven_install() after loading protobuf. Protobuf still doesn't define target overrides for itself so we still maintain those. When reorganizing the WORKSPACE I noticed http_archive should ideally be above io_grpc_grpc_java as most users will need it there, so I fixed that since there were lots of other load()-reordering already.
2021-12-08 08:18:46 +08:00
load("//:repositories.bzl", "grpc_java_repositories")
grpc_java_repositories()
load("@com_google_protobuf//:protobuf_deps.bzl", "PROTOBUF_MAVEN_ARTIFACTS")
load("@com_google_protobuf//:protobuf_deps.bzl", "protobuf_deps")
protobuf_deps()
bazel: Support maven_install maven_install is strongly superior to previous forms of grabbing dependencies from Maven as it computes the appropriate versions to use from the full transitive dependencies of all libraries used by an application. It also has much less boilerplate and includes dependencies with generated targets. In the future we will drop the jvm_maven_import_external usages and require maven_install, at which point we can swap to using the `@maven' repository and no longer depend on compat_repositories. Fixes #5359
2019-12-19 06:51:08 +08:00
Add Bazel build support for xds, googleapis to flesh out maven_install Not updating the example WORKSPACE because it doesn't have any Bazel-enabled build that depends on xds and so doesn't need the additional repository dependencies. Fixes #9162
2022-05-14 11:50:33 +08:00
load("@envoy_api//bazel:repositories.bzl", "api_dependencies")
api_dependencies()
load("@com_google_googleapis//:repository_rules.bzl", "switched_rules_by_language")
switched_rules_by_language(
name = "com_google_googleapis_imports",
java = True,
)
bazel: Support maven_install maven_install is strongly superior to previous forms of grabbing dependencies from Maven as it computes the appropriate versions to use from the full transitive dependencies of all libraries used by an application. It also has much less boilerplate and includes dependencies with generated targets. In the future we will drop the jvm_maven_import_external usages and require maven_install, at which point we can swap to using the `@maven' repository and no longer depend on compat_repositories. Fixes #5359
2019-12-19 06:51:08 +08:00
maven_install(
Upgrade Protobuf to 3.19.1 and Guava to 30.1.1 Protobuf uses Guava 30.1.1, so I upgrade it at the same time. It also caused an update to rules_jvm_external and reworking the Bazel build. Protobuf no longer requires bind() so they were dropped. Although Protobuf's protobuf_deps() brings in rules_jvm_external, and so we don't need to define it ourselves, it seems better to define it directly and not depend on transitive deps since we use it directly. Protobuf now has support for maven_install() by exposing PROTOBUF_MAVEN_ARTIFACTS, which required reorganizing the WORKSPACE to use maven_install() after loading protobuf. Protobuf still doesn't define target overrides for itself so we still maintain those. When reorganizing the WORKSPACE I noticed http_archive should ideally be above io_grpc_grpc_java as most users will need it there, so I fixed that since there were lots of other load()-reordering already.
2021-12-08 08:18:46 +08:00
artifacts = IO_GRPC_GRPC_JAVA_ARTIFACTS + PROTOBUF_MAVEN_ARTIFACTS,
bazel: Support maven_install maven_install is strongly superior to previous forms of grabbing dependencies from Maven as it computes the appropriate versions to use from the full transitive dependencies of all libraries used by an application. It also has much less boilerplate and includes dependencies with generated targets. In the future we will drop the jvm_maven_import_external usages and require maven_install, at which point we can swap to using the `@maven' repository and no longer depend on compat_repositories. Fixes #5359
2019-12-19 06:51:08 +08:00
generate_compat_repositories = True,
override_targets = IO_GRPC_GRPC_JAVA_OVERRIDE_TARGETS,
repositories = [
"https://repo.maven.apache.org/maven2/",
],
bazel: Support maven_install's strict_visibility=True This seems like a poorly thought-out feature for maven_install in a world where the dependency list is being combined from multiple repositories, as it means all Bazel-aware dependencies must subscribe to the idea this is good and useful. It also loses effectiveness as transitive dependencies are likely to be included directly in maven_install; users of gRPC can use netty, guava, and other dependencies without explicitly defining them even with strict_visibility=True. Given maven_install still complains about "Found duplicate artifact versions", it isn't too surprising it doesn't make sense in a multi-repo world. This isn't a bad feature for gRPC as we are pretty low-level and it can be helpful when making bazel dependency versions match gradle dependency versions. But it doesn't necessarily seem like something we need to be too worried about making sure we use. Similarly, don't use it in the example as it seems low-value for our users. Fixes #9288
2022-06-22 03:24:00 +08:00
strict_visibility = True,
bazel: Support maven_install maven_install is strongly superior to previous forms of grabbing dependencies from Maven as it computes the appropriate versions to use from the full transitive dependencies of all libraries used by an application. It also has much less boilerplate and includes dependencies with generated targets. In the future we will drop the jvm_maven_import_external usages and require maven_install, at which point we can swap to using the `@maven' repository and no longer depend on compat_repositories. Fixes #5359
2019-12-19 06:51:08 +08:00
)
load("@maven//:compat.bzl", "compat_repositories")
compat_repositories()