Want to contribute? Great! We try to make it easy, and all contributions, even the smaller ones, are more than welcome. This includes bug reports, fixes, documentation, examples... But first, read this page (including the small print at the end).
- Legal
- Reporting an issue
- Checking an issue is fixed in main
- Before you contribute
- Setup
- Usage
- The small print
Table of contents generated with markdown-toc
All original contributions to Jester are licensed under the ASL - Apache License, version 2.0 or later, or, if another license is specified as governing the file or directory being modified, such other license.
All contributions are subject to the Developer Certificate of Origin (DCO).
This project uses GitHub issues to manage the issues. Open an issue directly in GitHub.
If you believe you found a bug, and it's likely possible, please indicate a way to reproduce it, what you are seeing and what you would expect to see. Don't forget to indicate your Jester, Java, Maven/Gradle and GraalVM version.
Sometimes a bug has been fixed in the main branch of Jester and you want to confirm it is fixed for your own application.
If you are interested in having more details, refer to the Build section and the Usage section.
Just do the following:
git clone [email protected]:snowdrop/jester.git
cd jester
mvn clean install -Pframework
To contribute, use GitHub Pull Requests, from your own fork.
Also, make sure you have set up your Git authorship correctly:
git config --global user.name "Your Full Name"
git config --global user.email [email protected]
If you use different computers to contribute, please make sure the name is the same on all your computers.
We use this information to acknowledge your contributions in release announcements.
All submissions, including submissions by project members, need to be reviewed before being merged.
- We decided to disallow
@authortags in the JavaDoc: they are hard to maintain, especially in a very active project, and we use the Git history to track authorship. GitHub also has this nice page with your contributions. - Commits should be atomic and semantic. Please properly squash your pull requests before submitting them. Fixup commits can be used temporarily during the review process but things should be squashed at the end to have meaningful commits. We use merge commits so the GitHub Merge button cannot do that for us. If you don't know how to do that, just ask in your pull request, we will be happy to help!
Because we are all humans, and to ensure Jester is stable for everyone, all changes must go through Jester continuous integration. Jester CI is based on GitHub Actions, which means that everyone has the ability to automatically execute CI in their forks as part of the process of making changes. We ask that all non-trivial changes go through this process, so that the contributor gets immediate feedback, while at the same time keeping our CI fast and healthy for everyone.
The process requires only one additional step to enable Actions on your fork (clicking the green button in the actions tab) . See the full video walkthrough for more details on how to do this.
Don't forget to include tests in your pull requests. Also don't forget the documentation (reference documentation, JavaDoc...).
Be sure to test your pull request in:
- Java mode
- Native mode
If you have not done so on this machine, you need to:
- Install Git and configure your GitHub access
- Install Java SDK 11+ (OpenJDK recommended)
- Install Docker - Check the installation guide, and the MacOS installation guide
Jester has a strictly enforced code style. Code formatting is done by the Checkstyle plugin, using the config
file checkstyle.xml. By default when you run mvn clean install the code will be formatted automatically. When submitting a
pull request the CI build will fail if running the formatter results in any code changes, so it is recommended that you always
run a full Maven build before submitting a pull request.
After the build was successful, the artifacts are available in your local Maven repository.
Jester uses JaCoCo to generate test coverage. If you would like to generate the report
run mvn install -Pframework,examples,coverage, then change into the coverage-report directory and run mvn package. The
code coverage report will be generated in
target/site/jacoco/.
This currently does not work on Windows as it uses a shell script to copy all the classes and files into the code coverage module.
If you just need a report for a single module, run mvn install jacoco:report -Pcoverage in that module (or with -f ...).
This project is an open source project, please act responsibly, be nice, polite and enjoy!