HOWTO

Here’s some miscellaneous documentation about using Avatica.

Building from a source distribution

Prerequisites are Java (JDK 8 or later) on your path.

Unpack the source distribution .tar.gz file,cd to the root directory of the unpacked source,then build using maven:

  1. $ tar xvfz apache-calcite-avatica-1.16.0-src.tar.gz
  2. $ cd apache-calcite-avatica-1.16.0-src
  3. $ ./gradlew build

Running tests describes how to run more or fewertests.

Building from Git

Prerequisites are Git,and Java (JDK 8 or later) on your path.

Create a local copy of the GitHub repository,cd to its root directory,then build using maven:

  1. $ git clone git://github.com/apache/calcite-avatica.git avatica
  2. $ cd avatica
  3. $ ./gradlew build

Note: gdub simplifies ./gradlew build to gw build,and it simplifies cases like ../../gradlew … to gw … as well.

Running tests describes how to run more or fewertests.

Running tests

The test suite will run by default when you build, unless you specify-x test

  1. $ ./gradlew assemble # build the artifacts
  2. $ ./gradlew build -x test # build the artifacts, verify code style, skip tests
  3. $ ./gradlew check # verify code style, execute tests
  4. $ ./gradlew test # execute tests
  5. $ ./gradlew checkstyleMain checkstyleTest # verify code style

You can use ./gradlew assemble to build the artifacts and skip all tests and verifications.

To run tests in docker:

  1. docker-compose run test

Contributing

See the developers guide.

Getting started

See the developers guide.

Advanced topics for developers

The following sections might be of interest if you are adding featuresto particular parts of the code base. You don’t need to understandthese topics if you are just building from source and running tests.

Advanced topics for committers

The following sections are of interest to Calcite committers and inparticular release managers.

Set up PGP signing keys (for Calcite committers)

Follow instructions here tocreate a key pair. (On Mac OS X, I did brew install gpg andgpg —gen-key.)

Add your public key to theKEYSfile by following instructions in the KEYS file.(The KEYS file is not present in the git repo or in a release tarball because that would beredundant.)

Run a GPG agent

By default, Maven plugins which require you to unlock a GPG secret keywill prompt you in the terminal. To prevent you from having to enterthis password numerous times, it is highly recommended to install andrun gpg-agent.

This can be started automatically via an ~/.xsession on Linux or somescripting in your shell’s configuration script of choice (e.g. ~/.bashrc or ~/.zshrc)

  1. GPG_AGENT=$(which gpg-agent)
  2. GPG_TTY=`tty`
  3. export GPG_TTY
  4. if [[ -f "$GPG_AGENT" ]]; then
  5. envfile="${HOME}/.gnupg/gpg-agent.env"
  6. if test -f "$envfile" && kill -0 $(grep GPG_AGENT_INFO "$envfile" | cut -d: -f 2) 2>/dev/null; then
  7. source "$envfile"
  8. else
  9. eval "$(gpg-agent --daemon --log-file=~/.gpg/gpg.log --write-env-file "$envfile")"
  10. fi
  11. export GPG_AGENT_INFO # the env file does not contain the export statement
  12. fi

Also, ensure that default-cache-ttl 6000 is set in ~/.gnupg/gpg-agent.confto guarantee that your credentials will be cached for the duration of the build.

Set up Nexus repository credentials (for Calcite committers)

Gradle provides multiple ways to configure project properties.For instance, you could update $HOME/.gradle/gradle.properties.

Note: the build script would print the missing properties, so you can try running it and let it complain on the missing ones.

The following options are used:

  1. asfCommitterId=
  2. asfNexusUsername=
  3. asfNexusPassword=
  4. asfSvnUsername=
  5. asfSvnPassword=

Note: when https://github.com/vlsi/asflike-release-environment is used, the credentials are takend fromasfTest… (e.g. asfTestNexusUsername=test)

Note: if you want to uses gpg-agent, you need to pass useGpgCmd property, and specify the key idvia signing.gnupg.keyName.

Making a snapshot (for Calcite committers)

Before you start:

  • Set up signing keys as described above.
  • Make sure you are using JDK 8 (not 9 or 10).
  1. # Make sure that there are no junk files in the sandbox
  2. git clean -xn
  3. ./gradlew -Pasf publish

Making a release candidate (for Calcite committers)

Before you start:

  • Set up signing keys as described above.
  • Make sure you are using JDK 8 (not 9 or 10).
  • Check that README, site/_docs/howto.md, site/_docs/docker_images.md have the correct version number.
  • Check that NOTICE has the current copyright year.
  • Check that calcite.avatica.version has the proper value in /gradle.properties.
  • Add release notes to site/_docs/history.md. Include the commit history,and say which versions of Java, Guava and operating systems the release istested against.
  • Generate a report of vulnerabilities that occur among dependencies,using ./gradlew dependencyCheckUpdate dependencyCheckAggregate.
  • Make sure thatevery “resolved” JIRA case (including duplicates) hasa fix version assigned (most likely the version we arejust about to release)

The release candidate process does not add commits,so there’s no harm if it fails. It might leave -rc tag behindwhich can be removed if required.

You can perform a dry-run release with a help of https://github.com/vlsi/asflike-release-environmentThat would perform the same steps, however it would push changes to the mock Nexus, Git, and SVN servers.

If any of the steps fail, fix the problem, andstart again from the top.

To prepare a release candidate directly in your environment:

Pick a release candidate index and ensure it does not interfere with previous candidates for the version.

  1. # Make sure that there are no junk files in the sandbox
  2. git clean -xn
  3. # Dry run the release candidate (push to asf-like-environment)
  4. ./gradlew prepareVote -Prc=1
  5. # Push release candidate to ASF servers
  6. ./gradlew prepareVote -Prc=1 -Pasf

To prepare a release candidate in Docker:

  • You will need to have Docker and Docker Compose installed.

  • The script expects you to mount your ~/.gnupg directory into the /.gnupg directory in the container. Once mounted into the container,the script will make a copy of the contents and move it to a different location, so that it will not modify the contents of your original~/.gnupg directory during the build.

  • Start the asflike-release-environment to prepare a staging environment for a dry-run.

  1. # On Linux (dry-run):
  2. docker-compose run -v ~/.gnupg:/.gnupg dry-run
  3. # On Windows (dry-run):
  4. docker-compose run -v /c/Users/username/AppData/Roaming/gnupg:/.gnupg dry-run
  5. # On Linux (push to ASF servers):
  6. docker-compose run -v ~/.gnupg:/.gnupg publish-release-for-voting
  7. # On Windows (push to ASF servers):
  8. docker-compose run -v /c/Users/username/AppData/Roaming/gnupg:/.gnupg publish-release-for-voting

Checking the artifacts

  • In the release/build/distributions directory should be these 3 files, among others:
    • apache-calcite-avatica-X.Y.Z-src.tar.gz
    • apache-calcite-avatica-X.Y.Z-src.tar.gz.asc
    • apache-calcite-avatica-X.Y.Z-src.tar.gz.sha512
  • Note that the file names start apache-calcite-avatica-.
  • In the source distro .tar.gz (currently there isno binary distro), check that all files belong to a directory calledapache-calcite-avatica-X.Y.Z-src.
  • That directory must contain files NOTICE, LICENSE,README, README.md
    • Check that the version in README is correct
  • Make sure that there is no KEYS file in the source distros
  • For each .jar (for example core/build/libs/avatica-core-X.Y.Z.jarand server/build/libs/avatica-server-X.Y.Z-sources.jar),verify that the META-INF directory contains the correctcontents for LICENSE and NOTICE per thesource/classes contained. Refer to the ASF licensing documentation onwhat is required.
  • Check PGP, per this

Verify the staged artifacts in the Nexus repository:

  • Go to https://repository.apache.org/ and login
  • Under Build Promotion, click Staging Repositories
  • In the Staging Repositories tab there should be a line with profile org.apache.calcite
  • Navigate through the artifact tree and make sure the .jar, .pom, .asc files are present

Cleaning up after a failed release attempt (for Calcite committers)

If something is not correct, you can fix it, commit it, and prepare the next candidate.The release candidate tags might be kept for a while.

Validate a release

  1. # Check that the signing key (e.g. 2AD3FAE3) is pushed
  2. gpg --recv-keys key
  3. # Check keys
  4. curl -O https://dist.apache.org/repos/dist/release/calcite/KEYS
  5. # Sign/check sha256 hashes
  6. # (Assumes your O/S has a 'shasum' command.)
  7. function checkHash() {
  8. cd "$1"
  9. for i in *.{pom,gz}; do
  10. if [ ! -f $i ]; then
  11. continue
  12. fi
  13. if [ -f $i.sha256 ]; then
  14. if [ "$(cat $i.sha256)" = "$(shasum -a 256 $i)" ]; then
  15. echo $i.sha256 present and correct
  16. else
  17. echo $i.sha256 does not match
  18. fi
  19. else
  20. shasum -a 256 $i > $i.sha256
  21. echo $i.sha256 created
  22. fi
  23. done
  24. }
  25. checkHash apache-calcite-avatica-X.Y.Z-rcN

Get approval for a release via Apache voting process (for Calcite committers)

Release vote on dev list.Note: the draft mail is printed as the final step of prepareVote task,and you can find the draft in /build/prepareVote/mail.txt

  1. To: dev@calcite.apache.org
  2. Subject: [VOTE] Release apache-calcite-avatica-X.Y.Z (release candidate N)
  3. Hi all,
  4. I have created a build for Apache Calcite Avatica X.Y.Z, release candidate N.
  5. Thanks to everyone who has contributed to this release.
  6. <Further details about release.> You can read the release notes here:
  7. https://github.com/apache/calcite-avatica/blob/XXXX/site/_docs/history.md
  8. The commit to be voted upon:
  9. https://gitbox.apache.org/repos/asf/calcite-avatica/commit/NNNNNN
  10. Its hash is XXXX.
  11. The artifacts to be voted on are located here:
  12. https://dist.apache.org/repos/dist/dev/calcite/apache-calcite-avatica-X.Y.Z-rcN/
  13. The hashes of the artifacts are as follows:
  14. src.tar.gz.sha256 XXXX
  15. A staged Maven repository is available for review at:
  16. https://repository.apache.org/content/repositories/orgapachecalcite-NNNN
  17. Release artifacts are signed with the following key:
  18. https://people.apache.org/keys/committer/jhyde.asc
  19. Please vote on releasing this package as Apache Calcite Avatica X.Y.Z.
  20. The vote is open for the next 72 hours and passes if a majority of
  21. at least three +1 PMC votes are cast.
  22. [ ] +1 Release this package as Apache Calcite X.Y.Z
  23. [ ] 0 I don't feel strongly about it, but I'm okay with the release
  24. [ ] -1 Do not release this package because...
  25. Here is my vote:
  26. +1 (binding)
  27. Julian

After vote finishes, send out the result:

  1. Subject: [RESULT] [VOTE] Release apache-calcite-avatica-X.Y.Z (release candidate N)
  2. To: dev@calcite.apache.org
  3. Thanks to everyone who has tested the release candidate and given
  4. their comments and votes.
  5. The tally is as follows.
  6. N binding +1s:
  7. <names>
  8. N non-binding +1s:
  9. <names>
  10. No 0s or -1s.
  11. Therefore I am delighted to announce that the proposal to release
  12. Apache Calcite Avatica X.Y.Z has passed.
  13. Thanks everyone. Well now roll the release out to the mirrors.
  14. There was some feedback during voting. I shall open a separate
  15. thread to discuss.
  16. Julian

Use the Apache URL shortener to generateshortened URLs for the vote proposal and result emails. Examples:s.apache.org/calcite-1.2-vote ands.apache.org/calcite-1.2-result.

Publishing a release (for Calcite committers)

After a successful release vote, we need to push the releaseout to mirrors, and other tasks.

Choose a release date.This is based on the time when you expect to announce the release.This is usually a day after the vote closes.Remember that UTC date changes at 4pm Pacific time.

In JIRA, search forall issues resolved in this release,and do a bulk update changing their status to “Closed”,with a change comment“Resolved in release X.Y.Z (YYYY-MM-DD)”(fill in release number and date appropriately).Uncheck “Send mail for this update”.

Tip: Push the git tag only after the staged nexus artifacts are promoted in the repository. This is because pushing thetag triggers Docker Hub to start building the docker images immediately and the build will pull in the promoted artifacts.If the artifacts are not yet available, the build on Docker Hub will fail. It’s best to continue with the following stepsafter you have confirmed that the nexus artifacts were promoted properly.

Publishing directly in your environment:

  1. # Dry run publishing the release (push to asf-like-environment)
  2. ./gradlew publishDist -Prc=1
  3. # Publish the release to ASF servers
  4. ./gradlew publishDist -Prc=1 -Pasf

If there are more than 2 releases in SVN (see https://dist.apache.org/repos/dist/release/calcite),clear out the oldest ones:

  1. svn rm https://dist.apache.org/repos/dist/release/calcite/apache-calcite-avatica-X.Y.Z

The old releases will remain available in therelease archive.

Publishing a release using docker:

This assumes that a rc release was tagged and pushed to the git repository.

  1. docker-compose run promote-release

Add release notes and announce the release

Add a release note by copyingsite/_posts/2016-11-01-release-1.9.0.md,generate the javadoc and copy to site/target/avatica/javadocAggregatepublish the site,and check that it appears in the contents in news.

After 24 hours, announce the release by sending an email toannounce@apache.org.You can usethe 1.8.0 announcementas a template. Be sure to include a brief description of the project.

Publishing the web site (for Calcite committers)

See instructions insite/README.md.