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).
All original contributions to Quarkus 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). The DCO text is also included verbatim in the dco.txt file in the root directory of the repository.
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 Quarkus, Java, Maven/Gradle and GraalVM version.
To contribute, use GitHub Pull Requests, from your own fork.
All submissions, including submissions by project members, need to be reviewed before being merged.
Because we are all humans, the project uses a continuous integration approach and each pull request triggers a full build. Please make sure to monitor the output of the build and act accordingly.
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 (OpenJDK recommended)
- Install GraalVM
- Install platform C developer tools:
- Linux
- Make sure headers are available on your system (you'll hit 'Basic header file missing (<zlib.h>)' error if they aren't).
- On Fedora
sudo dnf install zlib-devel
- Otherwise
sudo apt-get install libz-dev
- On Fedora
- Make sure headers are available on your system (you'll hit 'Basic header file missing (<zlib.h>)' error if they aren't).
- macOS
xcode-select --install
- Linux
- Set
GRAALVM_HOME
to your GraalVM Home directory e.g./opt/graalvm
on Linux or$location/JDK/GraalVM/Contents/Home
on macOS
Docker is not strictly necessary: it is used to run the MariaDB and PostgreSQL tests which are not enabled by default. However it is a recommended install if you plan to work on Quarkus JPA support:
- Check the installation guide, and the MacOS installation guide
- If you just install docker, be sure that your current user can run a container (no root required). On Linux, check the post-installation guide
Quarkus has a strictly enforced code style. Code formatting is done by the Eclipse code formatter, using the config files
found in the ide-config
directory. By default when you run ./mvnw 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.
If you want to run the formatting without doing a full build, you can run ./mvnw process-sources
.
Open the Preferences window, and then navigate to Java -> Code Style -> Formatter. Click Import and then
select the eclipse-format.xml
file in the ide-config
directory.
Next navigate to Java -> Code Style -> Organize Imports. Click Import and select the eclipse.importorder
file.
Open the Preferences window (or Settings depending on your edition) , navigate to Plugins and install the Eclipse Code Formatter Plugin from the Marketplace.
Restart your IDE, open the Preferences (or Settings) window again and navigate to Other Settings -> Eclipse Code Formatter.
Select Use the Eclipse Code Formatter, then change the Eclipse Java Formatter Config File to point to the
eclipse-format.xml
file in the ide-config
directory. Make sure the Optimize Imports box is ticked, and
select the eclipse.importorder
file as the import order config file.
- Clone the repository:
git clone https://github.com/quarkusio/quarkus.git
- Navigate to the directory:
cd quarkus
- Invoke
./mvnw clean install
from the root directory
git clone https://github.com/quarkusio/quarkus.git
cd quarkus
./mvnw clean install
# Wait... success!
The default build does not create native images, which is quite time consuming.
Note that the full build with all tests is quite slow, you will usually want to build with -DskipTests
. This will also
skip creation of the integration-test runner jars. If you want to skip tests but still create the runners you can set
-DskipTests -Dquarkus.build.skip=false
You can build and test native images in the integration tests supporting it by using ./mvnw install -Dnative
.
By default the build will use the native image server. This speeds up the build, but can cause problems due to the cache
not being invalidated correctly in some cases. To run a build with a new instance of the server you can use
./mvnw install -Dnative-image.new-server=true
.
This project is an open source project, please act responsibly, be nice, polite and enjoy!
- IntelliJ fails to import Quarkus Maven project with
java.lang.OutOfMemoryError: GC overhead limit exceeded
In IntelliJ IDEA (version older than 2019.2
) if you see problems in the Maven view claiming java.lang.OutOfMemoryError: GC overhead limit exceeded
that means the project import failed.
To fix the issue, you need to update the Maven importing settings:
Build, Execution, Deployment
> Build Tools
> Maven
> Importing
> VM options for importer
To import Quarkus you need to define the JVM Max Heap Size (E.g. -Xmx1g
)
Note As for now, we can't provide a unique Max Heap Size value. We have been reported to require from 768M to more than 3G to import Quarkus properly.
- Build hangs with DevMojoIT running infinitely
./mvnw clean install
# Wait...
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.192 s - in io.quarkus.maven.it.GenerateConfigIT
[INFO] Running io.quarkus.maven.it.DevMojoIT
DevMojoIT require a few minutes to run but anything more than that is not expected. Make sure that nothing is running on 8080.
- The native integration test for my extension didn't run in the CI
In the interest of speeding up CI, the native build stage run_native_tests_stage
have been split into multiple steps.
This means that each new extension needs to be configured explicitly in azure-pipelines.yml
to have it's integration tests run in native mode