In 61f19d707a I swapped the signatures to use the version catalog. But I
failed to preserve the `@signature` extension and it all seemed to
work... But in fact all the animalsniffer tasks were completing as
SKIPPED as they lacked signatures. The build.gradle changes in this
commit are to fix that while still using version catalog.
But while it was broken violations crept in. Most violations weren't
too important and we're not surprised went unnoticed. For example, Netty
with TLS has long required the Java 8 API
`setEndpointIdentificationAlgorithm()`, so using `Optional` in the same
code path didn't harm anything in particular. I still swapped it to
Guava's `Optional` to avoid overuse of `@IgnoreJRERequirement`.
One important violation has not been fixed and instead I've disabled the
android signature in api/build.gradle for the moment. The violation is
in StatusException using the `fillInStackTrace` overload of Exception.
This problem [had been noticed][PR11066], but we couldn't figure out
what was going on. AnimalSniffer is now noticing this and agreeing with
the internal linter. There is still a question of why our interop tests
failed to notice this, but given they are no longer running on pre-API
level 24, that may forever be a mystery.
[PR11066]: https://github.com/grpc/grpc-java/pull/11066
Bazel had the dependency added because of #5046, where Guava was
depending on it as compile-only and Bazel build have "unknown enum
constant" warnings. Guava now has a compile dependency on j2objc, so
this workaround is no longer needed. There are currently no version skew
issues in Gradle, which was the only usage.
* context, all: move Context classes to grpc-api
clean up grpc-context since it has no source code: only add dep on grpc-api
add exclusion for all transitive deps of grpc-api - only guava
exclude grpc-context as a dependency from grpc-alts because all context code is in grpc-api now
api: 1.7 as target Java version for Context source-set of grpc-api
* core, census: fix the issues with android project pulling in old grpc-context version
* api,context: make changes to bazel build files to account for context code moving from context to api
This avoids the (often missing) evaluationDependsOn and fixes using
results from other projects without propagating those through
Configuration. It also reduces the number of useless classes pulled in
by down-stream tests, reducing the probability of rebuilds.
The expectation of fixtures is they help testing down-stream code that
use the classes in main. That applies to all the classes here except for
FakeClock and StaticTestingClassLoader. It would also apply to many
internal classes in grpc-testing, but let's consider cleaning that up
future work.
We have two versions of multiple projects, the non-shadow and the
shadow. When using project() references, things are mostly fine,
although we may test with a different version than our users would use.
However, when a dependency from Maven Central depends on a grpc
artifact, it pulls in the non-shadow configuration and messes up
gradle's tracking. We shouldn't be using the non-shadow configuration,
so this issue is sort of a blessing to improve the test reliability.
Gradle 7 will notice that there's a missing dependency, but it is not
deterministic and is very slow to test. Starting in Gradle 8 it is much
more reliably triggered which greatly helped the testing efforts. The
error in Gradle 7 looks like:
```
> Task :grpc-gcp-observability:interop:startScripts
Execution optimizations have been disabled for task ':grpc-gcp-observability:interop:startScripts' to ensure correctness due to the following reasons:
- Gradle detected a problem with the following location: 'grpc-java/netty/shaded/build/libs/grpc-netty-shaded-1.54.0-SNAPSHOT-original.jar'. Reason: Task ':grpc-gcp-observability:interop:startScripts' uses this output of task ':grpc-netty-shaded:jar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. Please refer to https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency for more details about this problem.
```
Fixes#9992
The version used by protoc-gen-grpc-java will be upgraded separately,
because of large C++ build changes necessary. But that won't impact
users at all. We are upgrading to protoc 22.3; only the grpc plugin is
not upgraded.
Bazel is upgraded for both Java and C++.
google-cloud-logging brings in xds, services, and netty-shaded versions
1.43.2. grpc-netty-shaded and xds use internal APIs, so their version
needs to align with grpc-api and grpc-core. OpenCensus stackdriver
components also brings in netty-shaded version 1.27.2, but it was later
in the dependency list so google-cloud-logging's versions won out even
if using Maven.
We don't need an explicit dependency on netty-shaded because xds depends
on it transitively.
This was discovered because our GAE interop test failed in the course of
PR #9858 which added grpc-gcp-observability to interop-testing (and thus
also gae-interop-test):
```
Caused by: java.lang.AbstractMethodError: io.grpc.ManagedChannelProvider.getSupportedSocketAddressTypes()Ljava/util/Collection;
at io.grpc.ManagedChannelRegistry.newChannelBuilder(ManagedChannelRegistry.java:186)
at io.grpc.ManagedChannelRegistry.newChannelBuilder(ManagedChannelRegistry.java:155)
at io.grpc.Grpc.newChannelBuilder(Grpc.java:101)
at io.grpc.testing.integration.LongLivedChannel.<init>(LongLivedChannel.java:44)
... 44 more
```
This can avoid creating an additional 736 tasks (previously 502 out of
1591 were not created). That's not all that important as the build time
is essentially the same, but this lets us see the poor behavior of the
protobuf plugin in our own project and increase our understanding of how
to avoid task creation when developing the plugin. Of the tasks still
being created, protobuf is the highest contributor with 165 tasks,
followed by maven-publish with 76 and appengine with 53. The remaining
59 are from our own build, but indirectly caused by maven-publish.
If I didn't upgrade X there is probably a reason, but worst-case the
reason was "I was lazy." I did the easy stuff, so if upgrading caused
problems of any real sort I skipped it and moved on. The main other
reason is there's some stuff we're more conservative about upgrading,
but you can't distinguish one from the other in this commit.
This moves our depedencies into a plain file that can be read and
updated by tooling. While the current tooling is not particularly better
than just using gradle-versions-plugin, it should put us on better
footing. gradle-versions-plugin is actually pretty nice, but will be
incompatible with Gradle 8, so we need to wait a bit to see what the
future holds.
Left libraries as an alias for libs to reduce the commit size and make
it easier to revert if we don't end up liking this approach.
We're using Gradle 7.3.3 where it was an incubating fetaure. But in
Gradle 7.4 is became stable.
This reverts commit 0963f3151d. This
causes dependency problems when importing into Google, as
google-auth-library-java needs to be upgraded and that requires an
upgrade to google-http-java-client to bring in
https://github.com/googleapis/google-http-java-client/pull/1505 .
Reverting for now and will roll forward once those upgrades are
performed.
Retryable was added in google-auth-library 1.5.3 to make clear the
situations that deserve a retry of the RPC. Bump to that version and
swap away from the imprecise IOException heuristic.
go/auth-correct-retry
Fixes#6808
Eric Anderson