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.
Currently, all ServiceTalk released artifacts are available in a Bintray repo: https://dl.bintray.com/servicetalk/servicetalk/, but will be published to Maven Central soon.
This repository must be configured in which ever build tool your project uses (e.g. Maven, Gradle, etc…).
<project>
...
<repositories>
<repository>
<id>bintray-servicetalk</id>
<url>https://dl.bintray.com/servicetalk/servicetalk/</url>
</repository>
</repositories>
...
</project>
repositories {
mavenCentral()
maven {
url "https://dl.bintray.com/servicetalk/servicetalk/"
}
}
For more information, see Bintray Maven Repositories docs.
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.
ServiceTalk’s build produces custom Gradle plugins and thus has regular (i.e. non-buildscript
) dependencies
on other plugins. This is the reason why the repositories that are provided if none are configured globally are the
following:
allprojects {
buildscript {
repositories {
jcenter()
maven { url "https://plugins.gradle.org/m2/" }
}
}
repositories {
jcenter()
maven { url "https://plugins.gradle.org/m2/" }
}
}
If you have defined repositories or repository mirrors in your global Gradle config (~/.gradle/init.gradle
),
the build will detect them and attempt to inherit buildscript
repositories into the main repositories
of the sub-projects that produce custom Gradle plugins.
Note
|
This inheritance mechanism can be disabled by setting a Gradle property:-PdisableInheritBuildscriptRepositories .
|
You should be able to run the following command to build ServiceTalk:
$ ./gradlew build
The supported IDE is IntelliJ IDEA. In order to generate IntelliJ IDEA project files for ServiceTalk, you can run the following command:
$ ./gradlew idea
When done, running one of following commands would open ServiceTalk in IntelliJ:
$ idea .
$ open servicetalk.ipr