We deploy GRPC to Maven Central under the following systems:
Other systems may also work, but we haven't verified them.
If you haven't deployed artifacts to Maven Central before, you need to setup your OSSRH (OSS Repository Hosting) account and signing keys.
gpg --keyserver pgp.mit.edu --send-key <key ID>).<your-home-directory>/.gradle/gradle.properties.# You need the signing properties only if you are making release deployment signing.keyId=<8-character-public-key-id> signing.password=<key-password> signing.secretKeyRingFile=<your-home-directory>/.gnupg/secring.gpg ossrhUsername=<ossrh-username> ossrhPassword=<ossrh-password> checkstyle.ignoreFailures=false
Protobuf libraries are needed for compiling the GRPC codegen. Despite that you may have installed Protobuf on your system, you may want to build Protobuf separately and install it under your personal directory, because
Please see the Main Readme for details on building protobuf.
The first step in the release process is to create a release branch and then from it, create a tag for the release. Our release branches follow the naming convention of v<major>.<minor>.x, while the tags include the patch version v<major>.<minor>.<patch>. For example, the same branch v0.7.x would be used to create all v0.7 tags (e.g. v0.7.0, v0.7.1).
Create the release branch:
$ git checkout -b v<major>.<minor>.x master
Next, increment the version in build.gradle in master to the next minor snapshot (e.g. 0.8.0-SNAPSHOT).
In the release branch, change the build.gradle to the next release version (e.g. 0.7.0)
Push the release branch to github
$ git push upstream v<major>.<minor>.x
In the release branch, create the release tag using the Major.Minor.Patch naming convention:
$ git tag -a v<major>.<minor>.<patch>
Push the release tag to github:
$ git push upstream v<major>.<minor>.<patch>
Update the build.gradle in the release branch to point to the next patch snapshot (e.g. 0.7.1-SNAPSHOT).
Push the updated release branch to github.
$ git push upstream v<major>.<minor>.x
The deployment for Linux uses Docker running CentOS 6.6 in order to ensure that we have a consistent deployment environment on Linux. You'll first need to install Docker if not already installed on your system. Make sure to have at least version 1.7.1 or later.
Under the Protobuf source directory, build the protoc-artifacts image:
protobuf$ docker build -t protoc-artifacts protoc-artifacts
Under the grpc-java source directory, build the grpc-java-deploy image:
grpc-java$ docker build -t grpc-java-deploy compiler
Start a Docker container that has the deploy environment set up for you. The GRPC source is cloned into /grpc-java.
$ docker run -it --rm=true grpc-java-deploy
Note that the container will be deleted after you exit. Any changes you have made (e.g., copied configuration files) will be lost. If you want to keep the container, remove --rm=true from the command line.
Next, you'll need to copy your OSSRH credentials and GnuPG keys to your docker container. Run ifconfig in the host, find the IP address of the docker0 interface. Then in Docker:
$ scp -r <your-host-user>@<docker0-IP>:./.gnupg ~/ $ mkdir ~/.gradle $ scp -r <your-host-user>@<docker0-IP>:./.gradle/gradle.properties ~/.gradle
You'll also need to update signing.secretKeyRingFile in /root/.gradle/gradle.properties to point to /root/.gnupg/secring.gpg.
Because the gcc shipped with MSYS2 doesn't support multilib, you have to compile and deploy 32-bit and 64-bit binaries in separate steps.
Compile and install 32-bit protobuf:
protobuf$ ./configure --disable-shared --prefix=$HOME/protobuf-32 protobuf$ make clean && make && make install
Configure CXXFLAGS needed by the protoc plugin when building.
grpc-java$ export CXXFLAGS="-I$HOME/protobuf-32/include" \ LDFLAGS="-L$HOME/protobuf-32/lib"
Compile and install 64-bit protobuf:
protobuf$ ./configure --disable-shared --prefix=$HOME/protobuf-64 protobuf$ make clean && make && make install
Configure CXXFLAGS needed by the protoc plugin when building.
grpc-java$ export CXXFLAGS="-I$HOME/protobuf-64/include" \ LDFLAGS="-L$HOME/protobuf-64/lib"
Because the MinGW gcc shipped with Cygwin64 doesn't support multilib, you have to compile and deploy 32-bit and 64-bit binaries in separate steps.
Compile and install 32-bit protobuf. -static-libgcc -static-libstdc++ are needed for protoc to be successfully run in the unit test.
protobuf$ LDFLAGS="-static-libgcc -static-libstdc++" ./configure --host=i686-w64-mingw32 --disable-shared --prefix=$HOME/protobuf-32 protobuf$ make clean && make && make install
Compile and install 64-bit protobuf:
protobuf$ ./configure --host=x86_64-w64-mingw32 --disable-shared --prefix=$HOME/protobuf-64 protobuf$ make clean && make && make install
Please refer to Protobuf README for how to set up GCC and Unix tools on Mac.
Mac OS X has been 64-bit-only since 10.7 and we are compiling for 10.7 and up. We only build 64-bit artifact for Mac.
Compile and install protobuf:
protobuf$ CXXFLAGS="-m64" ./configure --disable-shared --prefix=$HOME/protobuf protobuf$ make clean && make && make install
Configure CXXFLAGS needed by the protoc plugin when building.
grpc-java$ export CXXFLAGS="-I$HOME/protobuf/include" \ LDFLAGS="$HOME/protobuf/lib/libprotobuf.a $HOME/protobuf/lib/libprotoc.a"
We currently distribute the following OSes and architectures:
| OS | x86_32 | x86_64 |
|---|---|---|
| Linux | X | X |
| Windows | X | X |
| Mac | X |
Deployment to Maven Central (or the snapshot repo) is a two-step process. The only artifact that is platform-specific is codegen, so we only need to deploy the other jars once. So the first deployment is for all of the artifacts from one of the selected OS/architectures. After that, we then deploy the codegen artifacts for the remaining OS/architectures.
NOTE: Before building/deploying, be sure to switch to the appropriate branch or tag in the grpc-java source directory.
As stated above, this only needs to be done once for one of the selected OS/architectures. The following command will build the whole project and upload it to Maven Central.
grpc-java$ ./gradlew clean build && ./gradlew uploadArchives
If the version has the -SNAPSHOT suffix, the artifacts will automatically go to the snapshot repository. Otherwise it's a release deployment and the artifacts will go to a freshly created staging repository.
The previous step will only deploy the codegen artifacts for the OS you run on it and the architecture of your JVM. For a fully fledged deployment, you will need to deploy the codegen for all other supported OSes and architectures.
To deploy the codegen for an OS and architecture, you must run the following commands on that OS and specify the architecture by the flag -PtargetArch=<arch>.
If you are doing a snapshot deployment:
grpc-java$ ./gradlew clean grpc-compiler:build grpc-compiler:uploadArchives -PtargetArch=<arch>
When deploying a Release, the first deployment will create a new staging repository. You'll need to look up the ID in the OSSRH UI (usually in the form of iogrpc-*). Codegen deployment commands should include -PrepositoryId=<repository-id> in order to ensure that the artifacts are pushed to the same staging repository.
grpc-java$ ./gradlew clean grpc-compiler:build grpc-compiler:uploadArchives -PtargetArch=<arch> \ -PrepositoryId=<repository-id>
Once all of the artifacts have been pushed to the staging repository, the repository must first be closed, which will trigger several sanity checks on the repository. If this completes successfully, the repository can then be released, which will begin the process of pushing the new artifacts to Maven Central (the staging repository will be destroyed in the process). You can see the complete process for releasing to Maven Central on the [OSSRH site] (http://central.sonatype.org/pages/releasing-the-deployment.html).
After waiting ~1 day and verifying that the release appears on [Maven Central] (http://mvnrepository.com/), the last step is to document and publicize the release.
grpc-io@googlegroups.com). The title should be something that clearly identifies the release (e.g.GRPC-Java <tag> Released).