Skip to content

Latest commit

 

History

History
154 lines (109 loc) · 6.99 KB

CONTRIBUTING.md

File metadata and controls

154 lines (109 loc) · 6.99 KB
Raw

Contributing to Nessie

How to contribute

Everyone is encouraged to contribute to the Nessie project. We welcome of course code changes, but we are also grateful for bug reports, feature suggestions, helping with testing and documentation, or simply spreading the word about Nessie.

There are several ways to get in touch with other contributors:

More information are available at https://projectnessie.org/develop/

Code of conduct

You must agree to abide by the Project Nessie Code of Conduct.

Reporting issues

Issues can be filed on GitHub. Please use the template and add as much detail as possible. Including the version of the client and server, how the server is being run (eg docker image) etc. The more the community knows the more it can help :-)

Feature Requests

If you have a feature request or questions about the direction of the project please join the slack channel and ask there. It helps build a richer discussion and more people can be involved than when posting as an issue.

Large changes or improvements

We are excited to accept new contributors and larger changes. Please join the mailing list and post a proposal before submitting a large change. This helps avoid double work and allows the community to arrive at a consensus on the new feature or improvement.

Code changes

IntelliJ IDEA tips

Nessie uses antlr and protoc to generate source files. Those files are needed to build the Nessie project.

Tip: In the "Project" view (usually on the left) right-click on the [nessie] project, open the Maven sub-menu (at the bottom of the context menu), click on Generate Sources and Update Folders. This will generate the protobuf source files that are necessary to build Nessie via IntelliJ IDEA.

Note: Using the above method via the project's context menu is much quicker than running/clicking on Generate Sources and Update Folders for all projects from the Maven view (usually on the right).

Maven tips

A ./mvnw --threads 1C clean install runs basically "everything" except release/deployment stuff. This is often not necessary. Use one of these parameters to speed things up:

  • -Dquickly Just compiles code, no tests, does not build code under ui/, perftest/ and a few more.
  • -DskipTests Compiles everything, runs no tests.
  • -DskipITs Compiles everything, runs unit tests, but no integration tests.

Parallel Maven Builds

Building Nessie works fine with Maven Daemon mvnd.

Alternatively, use the provided Maven Wrapper ./mvnw with the -T1C (or --threads 1C) option.

Development process

The development process doesn't contain many surprises. As most projects on github anyone can contribute by forking the repo and posting a pull request. See GitHub's documentation for more information. Small changes don't require an issue. However, it is good practice to open up an issue for larger changes. If you are unsure of where to start ask on the slack channel or look at existing issues. The good first issue label marks issues that are particularly good for people new to the codebase.

For the Spark tests to run with Java 16 or newer, you need to update your ~/.m2/toolchains.xml to contain a reference to Java 11.

<?xml version="1.0" encoding="UTF-8"?>
<toolchains>
  <toolchain>
    <type>jdk</type>
    <provides>
      <version>11</version>
      <vendor>sun</vendor>
    </provides>
    <configuration>
      <jdkHome>PATH_TO_YOUR_JAVA_11_HOME</jdkHome>
    </configuration>
  </toolchain>
</toolchains>

Building with Java 17 (and 16)

Due to JEP 396, introduced in Java 16, a couple JVM options are required for google-java-format and errorprone to work. These options are harmless when using Java 11.

Apache Spark does only work with Java 11 (or 8), so all tests using Spark use the Maven toolchain mechanism to force Java 11 for the execution of those tests.

Maven Wrapper, Maven and Maven Daemon automatically pick up the necessary JVM options from .mvn/jvm.config or .mvn/mvnd.properties.

Style guide

Changes must adhere to the style guide and this will be verified by the continuous integration build.

  • Java code style is Google style.
  • Scala code style is scalafmt.
  • Python adheres to the pep8 standard.

Java and Scala code style is checked by Spotless with google-java-format and scalafmt during build.

Python code style is checked by flake8/black.

Automatically fixing code style issues

Java and Scala code style issues can be fixed from the command line using ./mvnw spotless:apply.

Python code style issues can be fixed from the command line using

cd python/

[ ! -d venv/ ] && virtualenv venv
. venv/bin/activate
pip install -U -r requirements_lint.txt
 
black pynessie tests

Configuring the Code Formatter for Intellij IDEA and Eclipse

Follow the instructions for Eclipse or IntelliJ, note the required manual actions for IntelliJ.

Code coverage

Code coverage is measured using jacoco plus codecov. The aggregator-project contains all modules that shall be measured. New modules must be added there as a dependency as well.

Submitting a pull request

Upon submission of a pull request you will be asked to sign our contributor license agreement. Anyone can take part in the review process and once the community is happy and the build actions are passing a Pull Request will be merged. Support must be unanimous for a change to be merged.

All pull-requests automatically trigger CI runs. Two long-running parts of the CI workflow are skipped for PRs by default, but can be enabled using "labels" on the PR.

  • Quarkus native image generation + tests against the native image. The label pr-native label enables this. The label pr-native label enables this, CI results do not appear as a separate job, because those run as part of the "Java/Maven" workflow job.
  • Nessie-client tests against various combinations of Jackson versions. The label pr-jackson label enables this and CI result will appear as a separate check.

Reporting security issues

Please see our Security Policy