Due to historical reasons, protobuf is in the proto2:: namespace
internally instead of google::protobuf. We have been maintaining diffs
that replace each occurence of one with the other. Instead we can simply
create a namespace alias and use that alias instead of the canonical
name. That greatly reduces the size of the diff and its likelihood to
break.
If the names ever align in the future, we can swap back to the canonical
names.
FALLTHROUGH_INTENDED was defined by Abseil, but is now getting an ABSL
prefix and the old name will be removed. Swapping to a new define name
to avoid redefining the existing-but-soon-to-be-deleted
FALLTHROUGH_INTENDED.
- Use gradle configuration `api` for dependencies that are part of grpc public api signatures.
- Replace deprecated gradle configurations `compile`, `testCompile`, `runtime` and `testRuntime`.
- With minimal change in dependencies: If we need dep X and Y to compile our code, and if X transitively depends on Y, then our build would still pass even if we only include X as `compile`/`implementation` dependency for our project. Ideally we should include both X and Y explicitly as `implementation` dependency for our project, but in this PR we don't add the missing Y if it is previously missing.
Examples and android projects were left unchanged. They can be changed
later.
No plugin versions were changed, to make this as non-functional of a
change as possible. Upgrading Gradle to 5.6 was necessary for
pluginManagement in settings.gradle.
* compiler: Use 'SERVICE_NAME' instead of duplicated '$Package$$service_name$'
* compiler: Align indentation
* Fix typo
* Add modified golden files and all re-generated code to meet Travis CI and Windows build requirements
See PR #5943
* Polishing
The 3rd-party rules_proto project is referencing our compiler directly
and not using our java_grpc_library. This target is fine for them to
use (although we'd prefer using our java_grpc_library), but most users
shouldn't be touching it.
Related to #5942 and #5947
This removes the "java_import to work around error with android_binary"
hack; see the b/78647825 references to see the really important parts.
But in general using a toolchain cleans up the code considerably and
allows us to reduce the visibility of our protoc plugin. It also is
useful to enable using aspects in the future to avoid using
make_non_strict() which would improve compilation speed avoid avoid many
unnecessary rebuilds.
This is an export of cl/229763103 and brings external up-to-sync with
internal.
For Bazel, we upgrade to protobuf 3.6.1.2 and javalite HEAD to fix
incompatibilities in newer Bazel releases.
compiler/Dockerfile is unused, so it was removed instead of being updated.
protoc no longer includes codegen for nano, so we remain on the older protoc
any time nano is used.
Protobuf now requires C++11 when compiling, so windows was swapped to
VC 14.
It appears everything was already working on Java 11, except
build-specific and testing issues. Updating to Netty 4.1.30 (#4940)
probably fixed the last true Java 11 incompatibility.
Fixes#4933