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.
The pinning is unreliable in Maven and ignored by Gradle. I'm not at all
convinced that we are pinning/not pinning in appropriate projects. The
pinning also serves less of a purpose since we started encouraging the
BOM and grpc-netty-shaded. Netty's HTTP/2 API has also become somewhat
stable compared to its earlier history. If we notice an up-tick in
version skew, we can reinstate it.
The pinning is annoying in the build.gradle code and causes Maven/Gradle
to download the version list once a day, which can be troublesome to
users unaware of how to tell the tools to work offline.
It also opens our users to platform issues like seen in #10043
and #10086 where Maven Central's version list was incorrectly generated.
Or like #9664 where Gradle Plugin's repository caches packages from
JCenter but the version list is not as cachable so exposed us to JCenter
instability.
This fixes#8357, by way of "we think we won't worry any more." See
90db93b9 when it was originally introduced. And issues
like #8337, #3634.
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++.
Instead of always overriding the bootstrap with a custom c2p config, now
we allow user defined ones to also be used. This only applies when
running in GCP with federation.
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
* api: add support for SocketAddress types in ManagedChannelProvider
also add support for SocketAddress types in NameResolverProvider
Use scheme in target URI to select a NameRseolverProvider and get
that provider's supported SocketAddress types.
implement selection in ManagedChannelRegistry of appropriate
ManagedChannelProvider based on NameResolver's SocketAddress types
GoogleCloudToProdNameResolver has a hard dependency on alts whereas xds
only has a weak dependency on alts that can be solved by a
ChannelCredentialsRegistry. So split out the code to a separate
artifact.
Eric Anderson