Thank you for your interest in contributing to Apache Camel.
In this document, we provide some guidelines on approaching the Apache Camel community and how to contribute to the community in the best possible way.
Please remember that a community is much more than just code. There are many ways you can help make Camel a better piece of software. Please dive in and help!
Try surfing the documentation: if something confuses you, bring it to our attention or suggest an improvement.
Download the code & try it out and see what you think.
Browse the source code. Got an itch to scratch, want to tune some operation, or add some feature?
Want to do some hacking on Camel? Try surfing on our issue tracker for open issues, feature requests, and planned tasks. Take ownership of a particular issue, and try to fix it.
Leave a comment on the issue to let us know you are working on it, and add yourself as a watcher to get informed about all modifications.
Identify areas you can contribute initially. You don’t have to be an expert in an area, the Apache Camel developers are available to offer help and guidance.
Introduce yourself on the developers' mailing-list, tell us what area of work or problem you wish to address in Camel. Create a draft of your solution, which can be simple 1-2 sentences on the change you wish to make. Try to be as specific as you can: include a short description of your intent, what you tried and what did not work, or what you need help with. The best way of approaching the developers is by describing what you would like to work on and asking specific questions on how to get started. We will do our best to guide you and help you make your contribution.
We often participate in Google Summer of Code and Outreachy programs. For information about those, look at those program websites. If you wish to participate in either of those, follow the guidelines and schedule set by those programs. If you are unsure, please reach out using one of the communication channels, or ask on the developer’s mailing list for help.
Apache Camel is an Apache Software Foundation project. We do all communication in the open on the project mailing lists. You can read more on the reasoning behind this to get a better understanding of this.
There are various ways of communicating with the Camel community.
Subscribe to the developer’s mailing list for questions and guidance about how to contribute. To subscribe to the developer’s mailing list, you can send an e-mail to email@example.com.
You can check the mailing-list page for more information about Camel mailing lists and information about how to subscribe to each of them.
You can also reach us on the Zulip chat.
The Camel Core project uses the Apache Foundation Jira instance for tracking issues, tasks, and feature requests.
When creating a ticket on our issue tracker, please try to follow these guidelines:
Please describe the bug/issue clearly.
Be as specific as possible.
Provide as much information as you have.
Attach any files containing details about your problem: logs, pictures, and screenshots are welcome.
When reporting a bug, provide a reproducer or describe the steps to reproduce the problem.
Providing a reproducer can greatly increase the chances of your request being handled quickly.
There are few ways you can provide a reproducer:
Create a JUnit test case that reproduces the problem. You can look at some of the existing unit test cases to learn about how to create one.
Create a sample project that reproduces the issue.
Provide route files, Kamelets or any other file we can run with Camel JBang.
We appreciate all reproducers, but there are a few tips that can make us appreciate it even more!
Reproducers provided as tests to Camel Core code base are easier for the community to work with than external applications.
Make sure to check the "Making a good contribution" section below for more details.
When an external application is required, reduce debugging friction:
Use the plain Camel Core (i.e.: if it’s a problem on Camel Core, avoid creating a reproducer based on Camel Quarkus, Camel Spring Boot and others).
Use Java: the Camel Core is written in Java and that’s the language the community is most familiar with.
Reproducers using Camel JBang are also highly helpful.
You can easily create an external reproducer using the following command:
Make sure to replace the camel version in
You will need to register to create or comment on JIRA issues. The “Log In” link in the upper right will allow you to log in with an existing account or sign up for an account.
Documentation is extremely important to help users make the most of Apache Camel, and it’s probably the area that needs the most help!
If you are interested in helping the documentation effort, whether it’s just to fix a page here or there, correct a link or even write a tutorial or improve existing documentation, please do dive in and help! Most of the documentation is managed in the same repositories as the related source code, so the process is similar to working on the code.
For more details, please refer to Improving the Documentation Guide in the User Manual.
We recommend forking the code from the camel GitHub repository.
git clone https://github.com/your-github/camel.git cd camel
Alternatively, if you are using the GitHub CLI:
gh repo fork apache/camel cd camel
Then, create a branch to work on your changes:
git branch my-new-feature git checkout my-new-feature
To build the project, you need Apache Maven.
To build Camel 3, you need Java 11 and Apache Maven version 3.6.x or newer.
To build Camel 4, you need Java 17 Apache Maven version 3.9.x or newer.
The following command will do a fast build.
mvn clean install -Dquickly
On Camel 4, you can also use
You can find more details about building Camel on the Building Camel page.
Tips: if you aren’t able to build a component after adding some new URI parameters due to
Empty doc for option: [OPTION], parent options: <null> please make sure that you either added properly javadoc for get/set method or description in
If you need to implement tests for your changes (highly recommended!), you will probably need to handle 3 separate things: - simulate the infrastructure required for the test (i.e.; JMS brokers, Kafka, etc), - writing testable code, - the test logic itself.
Naturally, there is no rule of thumb for how the code changes, and test logic should be written. The Testing page in the User Manual provides detailed information and examples for writing Camel unit tests.
Concerning simulating the test infrastructure, Camel has a growing library of reusable components that can be helpful: the test infra components. These components are located in the test-infra module and provide support for simulating message brokers, cloud environments, databases, and much more.
Using these components is usually as simple as registering them as JUnit 5 extensions:
@RegisterExtension static NatsService service = NatsServiceFactory.createService();
Then you can access the service by using the methods and properties provided by the services. This varies according to each service.
If you need to implement a new test-infra service, check the readme on the test-infra module for additional details.
Apache Camel source code uses a coding style/format that can be verified for compliance using the "checkstyle" plugin.
To enable source style checking, build Camel with the
mvn clean install -Psourcecheck
Please remember to run this check on your code changes before submitting a patch or GitHub PR. You do not need to run this against the entire project, but only in the modules you modified.
For instance, if you do some code changes in the camel-ftp component, following which you can run the check from within this directory:
cd camel-ftp mvn clean install -Psourcecheck
We gladly accept patches if you can find ways to improve, tune, or fix Camel in some way.
Make sure you have followed the steps and guidelines outlined in this document. For larger changes, make sure that you have discussed them on the developer’s mailing list or in the Jira issue tracker beforehand.
To get the best response from the team, make sure that the reasoning behind the contribution you wish to make is clear: outline the problem and explain your solution for it. Describe any changes you have made for which you are unaware or unsure of any consequences or side effects.
Be mindful of the source checks, formatting, and structure of the git commit message we abide by. In particular, if there is a JIRA issue, reference it in the first line of your commit message, for example:
CAMEL-9999: Some message goes here
Ensure that the unit tests include proper assertions.
Avoid simply outputting changes to the standard output/error or just logging.
Please also avoid unnecessary changes, like reordering methods and fields, which will make your PR harder to review.
When submitting a performance improvement, providing JMH test data as evidence or adding a JMH-based test on the camel-performance-tests repository is strongly recommended.
Be responsive, assume good intent and respect the Code of Conduct
When contributing components, please make sure that their dependencies are available in the Maven Central. We do not accept contributions if the dependencies are not publicly available.
Tests must follow the following naming convention:
*Test.java(i.e.: MyComponentTest.java) for unit tests.
*IT.java(i.e.: MyComponentIT.java) for integration tests.
*ManualTest.java(i.e.: MyComponentManualTest.java) for manual tests.
Thread.sleep(they make our tests slow and unreliable)
To disable tests use JUnit’s @Disabled annotation or one of its siblings (i.e.:
Following these guidelines will help you in getting your contribution accepted.
The preferred way to submit your changes is by opening a pull request (PR) on GitHub.
You can open a pull request via GitHub website or using the GitHub CLI. You can find many resources online explaining how to work on GitHub projects and how to submit work to these projects.
After your PR is opened, it will be reviewed by one or more of the Camel committers. They will evaluate if the code complies with ASF guidelines, appropriateness and correctness of the code. Eventually, they may ask questions, raise concerns and provide comments.
To open a PR using the CLI, you can use a command similar to the following:
gh pr create --title "CAMEL-9999: My new awesome Camel feature" --body "This introduces the new awesome feature described on CAMEL-9999"
The code will be tested automatically. The access to the build and test logs is restricted, but you can ask the committers to provide them for you in case of test failures.
For smaller patches, you may also submit a patch file instead of using a Pull Request. To do this:
Attach the patch or tarball as an attachment
Tick the Patch Attached button on the issue
Most IDEs can create nice patches now very easily. Then save the patch as a file and attach it to the corresponding JIRA issue.
If you prefer working on the command line, try the following to create the patch:
diff -u Main.java.orig Main.java >> patchfile.txt
git diff --no-prefix > patchfile.txt
After the code was integrated into the Camel repository, you can watch the Apache Continuous Integration instance to double-check that it worked and no side effects were introduced. You can watch the following jobs:
Our CI has many other jobs, covering different JDKs, platforms (x86, PowerPC, s390x, etc,) and projects. If in doubt, ask.
Once you have become sufficiently involved with the community, we may well invite you to be a committer. See How do I become a committer for more details.