ServiceTalk is a JVM network application framework with APIs tailored to specific protocols (e.g. HTTP/1.x, HTTP/2.x, etc…) and supports multiple programming paradigms.
It is built on Netty and is designed to provide most of the performance/scalability benefits of Netty for common networking protocols used in service to service communication. ServiceTalk provides server support and "smart client" like features such as client-side load balancing and service discovery integration.
See the ServiceTalk docs for more information.
ServiceTalk releases are available on Maven Central.
Refer to the ServiceTalk docs for various examples that will get you started with the different features of ServiceTalk.
|
Note
|
Builds of the development version are available in Sonatype’s snapshots Maven repository. |
ServiceTalk follows SemVer 2.0.0. API/ABI breaking changes will require package renaming for that module to avoid runtime classpath conflicts.
|
Note
|
0.x.y releases are not stable and are permitted to break API/ABI.
|
|
Important
|
If you’re intending to contribute to ServiceTalk, make sure to first read the contribution guidelines. |
ServiceTalk uses Gradle as its build tool and only requires JDK 8 or higher to be pre-installed. ServiceTalk ships with the Gradle Wrapper, which means that there is no need to install Gradle on your machine beforehand.
ServiceTalk’s source code is UTF-8 encoded: make sure your filesystem supports it before attempting to build
the project. Setting the JAVA_TOOL_OPTIONS env var to -Dfile.encoding=UTF-8 should help building the project in
non-UTF-8 environments. Editors and IDEs must also support UTF-8 in order to successfully edit ServiceTalk’s source
code.
You should be able to run the following command to build ServiceTalk and verify that all tests and code quality checks pass:
$ ./gradlew buildThe supported IDE is IntelliJ IDEA. In order to generate IntelliJ IDEA project files for ServiceTalk, you can run the following command:
$ ./gradlew ideaWhen done, running one of following commands would open ServiceTalk in IntelliJ:
$ idea .$ open servicetalk.iprServiceTalk uses JaCoCo for code coverage. Coverage is not wired into
./gradlew build to keep the default build fast; it is generated on demand.
To generate an aggregate coverage report across all modules, run:
$ ./gradlew testCodeCoverageReportThis runs the tests first, then merges the per-module coverage data. The combined report is written to:
-
HTML:
build/reports/jacoco/aggregate/html/index.html -
XML:
build/reports/jacoco/aggregate/jacocoAggregateReport.xml(for CI tooling)
To generate a report for a single module instead, run its jacocoTestReport task, for example:
$ ./gradlew :servicetalk-concurrent-api:jacocoTestReportThe aggregate report configuration lives in gradle/jacoco.gradle; the per-module setup is applied by the
ServiceTalk Gradle plugin.
We use lock files to ensure that all changes to dependencies are intentional, and don’t go unnoticed.
When updating dependencies, first make the intended modifications to gradle.properties, then run the following command to update the lock files:
$ ./gradlew resolveAndLockAll --write-locksWe encourage your participation asking questions and helping improve the ServiceTalk project. Github issues and pull requests are the primary mechanisms of participation and communication for ServiceTalk.