This is a sync from our internal copy, so has lots of small changes.
But the most important change is strict_deps issues are worked around
within the rule. This means there should be no longer any reason to
specify more than one dep.
Our Bazel CI is still on Bazel 0.20, so for the moment avoid requiring
Bazel 0.22 by staying on the old 'proto' provider instead of ProtoInfo.
Fixes#5314
gRPC's protobuf-lite auto-selects between full and lite protobuf based on the
value of crosstool_top. If the user is specifying their own
--android_crosstool_top, then it will not auto-detect correctly. One day,
platforms will fix problems like this, but for the moment it seems we get to
live with it.
They were removed in 137c74d1 since it was believed they were unnecessary.
However, since they are in a macro and not a rule, they are relative to the
caller, not their definition.
Added building the examples to the kokoro CI. Note that this means the examples
are built twice: once in grpc-java's build and once in their own (because it
has a WORKSPACE). Given that the Bazel build is our fastest build, this
slowdown won't probably be an issue.
This was deprecated with Bazel 0.8.0, which now uses
@com_google_protobuf instead.
This change will break users that use
grpc_java_repositories(omit_com_google_protobuf_java=True), so I've
added a custom error message to make the resolution clearer.
_path_ignoring_repository munges bazel filesystem paths into proto
import paths, in order to pass to protoc -I. Currently, the function
assumes that the include's path begins with the bazel workspace root,
which can therefore be sheared off the front of the path.
This assumption is incorrect. For an include living in an external
repository (say, `@com_google_protobuf//:timestamp_proto`),
the filesystem path is something like
`bazel-out/darwin_x86_64-fastbuild/genfiles/external/com_google_protobuf/google/protobuf/timestamp.proto`.
(See also:
http://docs.bazel.build/versions/master/skylark/lib/Label.html#workspace_root.)
This commit changes _path_ignoring_repository to handle this case correctly.
This commit aligns the naming of the Bazel Maven jars with the names
used by Bazel's migration-tooling project:
https://github.com/bazelbuild/migration-tooling
Unfortunately, we can't fix @com_google_protobuf_java because it's
required by Bazel itself.
Fixes#3328
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
Eric Anderson