`-link` does I/O to download the package list, for every javadoc
invocation. There is no caching, so this happens many times per build.
Swap to offline mode to avoid spamming the servers, and avoid build
failures if the servers aren't entirely healthy.
* Mark MultiChildLoadBalancer as Internal. Cannot move to the internal package because of its use of classes in the util package.
* Exclude MultiChildLoadBalancer from javadoc generation.
* Fix javadoc creation.
While JacocoReportBase.getExecutionData() is properly annotated with
`@InputFiles` and is a FileCollection, which can propagate dependencies,
the JacocoPlugin's configuration of the task [goes through a
File][barefile], which doesn't propagate task dependency information.
This is overcome in the plugin by mustRunAfter. This may have been on
purpose to allow jacocoTestReport to report on the subset of tests
already run, but is atypical these days.
Because of that, we need to copy the mustRunAfter from the other
JacocoTestReports. The dependsOn weren't doing anything because there
were no dependsOn; that configuration is quite old so it's hard to say
when they stopped functioning.
This fixes warnings like:
```
- Gradle detected a problem with the following location: 'grpc-java/core/build/jacoco/test.exec'. Reason: Task ':grpc-all:jacocoTestReport' uses this output of task ':grpc-core:test' 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.
- Gradle detected a problem with the following location: 'grpc-java/testing/build/resources/main'. Reason: Task ':grpc-all:jacocoTestReport' uses this output of task ':grpc-testing:processResources' 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.
```
I was able to trigger the warnings by:
```
./gradlew clean
./gradlew :grpc-core:test
./gradlew :grpc-all:jacocoTestReport
./gradlew :grpc-core:test :grpc-all:jacocoTestReport
```
[barefile]: bc4029063c/subprojects/jacoco/src/main/java/org/gradle/testing/jacoco/tasks/JacocoReportBase.java (L162-L168)
grpc-context is empty, so isn't needed. Including it also causes the
warning:
```
> Task :grpc-all:javadoc
Resolution of the configuration :grpc-context:compileClasspath was attempted from a context different than the project context. Have a look at the documentation to understand why this is a problem and how it can be resolved. This behaviour has been deprecated and is scheduled to be removed in Gradle 8.0. See https://docs.gradle.org/7.6/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors for more details.
```
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++.
Full end to end implementation of gRPC server as a Servlet including tests and examples
Co-authored-by: Penn (Dapeng) Zhang <zdapeng@google.com>
Co-authored-by: Chengyuan Zhang <chengyuanzhang@google.com>
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.
These changes make the build compatible with Gradle 7, except for
Android which requires plugin updates.
I removed animalsniffer from binder because it did nothing (as there
were no signatures) and it was failing after setting toolVersion. It
failed because animalsniffer is only compatible with java plugin. After
this change I put the withId(animalsniffer) loading inside the
withId(java) to avoid a plugin ordering failure. That made it safe again
for binder to load animalsniffer, but it is still best to remove the
plugin from binder as it is misleading.
I did not upgrade Android plugin versions as newer versions (even 3.6)
require dealing with androidx (#8421).
Back in 10fb206 when this for loop was added, we didn't have the
subprojects list. That was added in 9bd7bab, but I failed to update one
reference to rootProject. So all has had an evaluation dependency on all
projects, even though it only needs a subset.
This should have little impact, but would prevent weird scenarios like
an issue in :grpc-gae-interop-testing-jdk8 preventing :all-all from
being loaded. Not to say things wouldn't still fail to load, but that
this bug could distract from the real problem. I noticed this
during #8049.
- 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.
The sourceSets.main.output.collect should probably be improved at some point to
improve loading performance, but this is technically better than what we had
before so let's call it a win and move on.
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.
io.grpc has fewer dependencies than io.grpc.internal. Moving it to a
separate artifact lets users use the API without bringing in the deps.
If the library has an optional dependency on grpc, that can be quite
convenient.
We now version-pin both grpc-api and grpc-core, since both contain
internal APIs.
I had to change a few tests in grpc-api to avoid FakeClock. Moving
FakeClock to grpc-api was difficult because it uses
io.grpc.internal.TimeProvider, which can't be moved since it is a
production class. Having grpc-api's tests depend on grpc-core's test
classes would be weird and cause a circular dependincy. Having
grpc-api's tests depend on grpc-core is likely possible, but weird and
fairly unnecessary at this point. So instead I rewrote the tests to
avoid FakeClock.
Fixes#1447
This PR adds an automatic gradle format checker and reformats all the *.gradle files. After this, new changes to *.gradle files will fail to build if not in good format, just like checkStyle failure.
grpc-protobuf-lite brings in protobuf-lite as a dependency, which has
different versions of classes in protobuf. This causes duplicate classes
on the class path, which easily breaks things. Since lite the lite
runtime/codegen is incompatible with full protobuf, it makes sense to
only depend on one of the two.
grpc-protobuf actually already has a dependency on grpc-protobuf-lite,
but excludes the protobuf-lite dependency, making the dep safe. But this
is more of an implementation detail.
We only change deps so that JavaDoc, code coverage, and similar will
still include grpc-protobuf-lite.
Fixes#2985
The Context API is not particularly gRPC-specific, and will be used by
Census as its context propagation mechanism.
Removed all dependencies to make it easy for other libraries to depend
on.
grpc-all contains a copy of all the classes and sources of "important"
artifacts. The copy causes problems when grpc-all is mixed with the
individual artifacts like grpc-netty or grpc-core, since they will
collide on the classpath. Avoiding the copy fixes the problem.
See #1597
Codecov.io provides patch-based code coverage, so you can easily know
how many of the added lines are covered. It also has a more useful UI.
Unfortunately, the percentage it reports does not include partially-
covered lines--those with uncovered conditions. Thus the reported
percentage is about 6% lower than the coverage we've been looking at
previously. Because of this alone, I don't expect to remove coveralls
support soon.
Use the bash script instead of python module since pip isn't available
by default on Travis OS X.
jacocoTestReport uses mustRunAfter (contrary to the docs; see
https://issues.gradle.org/browse/GRADLE-2960) to make sure it runs after
all tests, only if testing is taking place. We would like
:grpc-all:jacocoTestReport to behave the same way. Without it, we would
need two separate invocations of gradle (adding ~1m to Travis run) in
order to prevent getting random results depending on what tests just so
happened to have been run.
After running tests, you can run jacocoTestReport. The jacocoTestReport
task does not depend on the tests, so they should be run separately.
There is still a lot of noise in the jacoco output since we aren't yet
filtering generated code.
Eric Anderson