native-imagecommand installed and
GRAALVM_HOMEenvironment variable set, see Building a native executable section of the Quarkus documentation.
If your are on Linux,
dockeris sufficient for the native mode too. Use
-Pnativeif you choose this option.
Maven 3.6.2+ (unless you use the Maven Wrapper, a.k.a.
mvnwavailable in the source tree).
Checkout the code
$ git clone https://github.com/apache/camel-quarkus.git $ cd camel-quarkus
A fast build without tests:
$ mvn clean install -DskipTests
A build with integration tests in the JVM mode only:
$ mvn clean install
A build with integration tests in both the JVM mode and the native mode:
$ mvn clean install -Pnative
You should know how to build.
Go through the Quarkus extension author’s guide to get an idea what is expecting you.
Make sure that nobody else works on the same extension already by searching through the GitHub issues.
Let others know that you work on the given extension by either creating a new issue or asking to assign an existing one to you.
Scaffold the necessary Maven modules using
quarkus-maven-plugin. As an example let’s add a new extension for supporting an imaginary Camel component
$ cd camel-quarkus $ mvn cq:create -N -Dcq.artifactIdBase=foo-abc
foo-abcis the unique part of the new extension’s
The above sequence of commands does the following:
It creates three new Maven modules under the
camel-quarkus-foo-abc(a.k.a. the runtime module) and
These three modules are linked where necessary:
camel-quarkus-foo-abc-parentis added to the
camel-quarkus-foo-abcis added to the
<dependencyManagement>of the runtime BOM (Bill of Materials)
camel-quarkus-foo-abc-deploymentis added to the
<dependencyManagement>of the deployment BOM (Bill of Materials)
It creates a basic
FooAbcProcessorclass in the deployment module.
It also creates a stub of an integration test module under
A compilation performed immediately after generating the modules should pass flawlessly but running the tests will fail because the test project needs to get finished. You need to build
poms/bom-deploymentone time first.
Review the generated
extensions/foo-abc/runtime/src/main/resources/META-INF/quarkus-extension.yamlfile. If you see improper description or keyword, file a new Camel issue and ask to fix the metadata for the given Camel component.
Review the dependencies in the generate runtime and deployment modules. In case the given library is supported by Quarkus, you may want to add a dependency on the corresponding Quarkus extension.
Complete the integration test module under
integration-tests/foo-abc. Make sure you test both the consumer and the producer of the component (if the component supports both). Make sure the tests are passing both in the JVM mode (
mvn test) and in the native mode (
mvn verify -Pnative).
If the usage of your new extension differs from the usage of the given Camel component, please add an AsciiDoc page under
docs/modules/ROOT/pages/extensionsand document the differences and Quarkus specific configuration options there. For our imaginary Camel component
foo-abcthe path of the page would be
docs/modules/ROOT/pages/extensions/foo-abc.adoc. After completing the page, run
mvn clean install -DskipTestsfrom the root of the source tree to add your extension to the autogenerated list of extensions.
Before sending a pull request, please make sure you have run the following Maven command from the project root folder:
$ mvn process-resources -Pformat
The above command will perform the following tasks:
Add license headers to the new files
Re-generate the list of extensions and the Camel Quarkus Catalog
Sort elements in various POM files properly
Review the result visually.
Please squash your commits before sending a pull request.