Page edited by Aki Yoshida

Changes (1)

Full Content

There are many ways you can help make Camel a better piece of software - please dive in and help!

Try surf the documentation - if somethings confusing or not clear, let us know. 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 the our issue tracker for open issues or features that need to be implemented, take ownership of an issue and try fix it.

If you are a new Camel rider and would like to help us, you can also find some easy to resolve issues. 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.

If you'd rather a more gentle introduction to working on the Camel project, how about you try look at the
test coverage report and help us get it even more green by supplying more test cases to get us closer to 100% coverage.

Warning
Apache Camel code repository was moved to git, The old svn repo is no longer updated. And this page referring to svn usage must be updated.
Until then, please refer to the git usage section on the Source page.

Getting in touch

There are various ways of communicating with the Camel community.

join us on the Discussion Forums and take part in any conversations
pop by on IRC and say hi
add some comments to the wiki

Improving the documentation

Documentation is massively important to help users make the most of Apache Camel and its probably the area that needs the most help!

So if you are interested in helping the documentation effort; whether its just to fix a page here or there, correct a link or even write a tutorial or improve what documentation is already there please do dive in and help!

All of the documentation is stored on the wiki. See How does the website work or How do I edit the website for more details.

To be able to edit the wiki you need to mail the dev list asking for an account (to prevent spam we only offer access to the wiki by folks sending mail to the mailing list).

If you find a bug or problem

Please raise a new issue in our issue tracker

If you can create a JUnit test case then your issue is more likely to be resolved quicker.
e.g. take a look at some of the existing unit tests cases

Then we can add your issue to Subversion and then we'll know when its really fixed and we can ensure that the problem stays fixed in future releases.

Working on the code

Grab the Source and create a project in your IDE. e.g. if you are using Eclipse the following should do the trick...

svn co https://svn.apache.org/repos/asf/camel/trunk camel
cd camel
mvn eclipse:eclipse

Build the project.

mvn install

PS: You might need to build multiple times (if you get a build error) because sometimes maven fails to download all the files.

Then import the projects into your workspace.

Creating patches

We gladly accept patches if you can find ways to improve, tune or fix Camel in some way.

Most IDEs can create nice patches now very easily. e.g. in Eclipse just right click on a file/directory and select Team -> Create Patch. Then just save the patch as a file and then submit it. (You may have to click on Team -> Share... first to enable the Subversion options). Incidentally if you are an Eclipse user you should install the subclipse plugin.

If you're a command line person try the following to create the patch

diff -u Main.java.orig Main.java >> patchfile.txt

svn diff Main.java >> patchfile.txt

Submitting patches

The easiest way to submit a patch is to

create a new JIRA issue (you will need to register),
attach the patch or tarball as an attachment
tick the Patch Attached button on the issue
fire off an email to the Discussion Forums linking to the JIRA

When a ticket is create in JIRA it automatically sends an email to the developer forum but an email always helps alert folks (as lots of emails are generated from every change to every JIRA).

Remember to create and attach the patch in two steps, as JIRA does not support granting ASF license to the patch in the create ticket wizard. So after creating the ticket, then attach the patch and remember to tick off the grant ASF license, otherwise we can not commit the patch. We prefer patches has unit tests as well and that these unit tests have proper assertions as well, so remember to replace your system.out or logging with an assertion instead!

Working with Git

While several committer are working with Git, it is not the primary version control system at Apache Software Foundation. This is because the ASF has to ensure that each commit into the codebase is correct licensed. With the current VCS - Subversion - only committers with a signed CLA have write access.

But there are several ways how Git users could improve Camel with their prefered tool:

git-svn
Apache Git Mirror
Pull request at Github

The minor "problem" is creating the local repository connected to the official repository. Next step is modifying the codebase. The major "problem" then is getting the modifications back to the official ASF repository.
Depending on the chosen way these steps differ which is short described here.

git-svn

With Git you cannot fork another Git repository - you also could "fork" a subversion repository.

git svn clone https://svn.apache.org/repos/asf/camel/trunk <TargetDirectory>

If you have write access to the codebase you could fork from the https-adress and just "push" your changes back:

git svn dcommit -m "message"

Without that privilege you could follow the recommended workflow: working on a feature branch, create a patch and attach it to Jira. Attaching to Jira has the benefit for the community that you are enforced to grant explicitly the license to the ASF.

git format-patch origin/trunk

Apache Git Mirror

Forking the Git repo from here is much smoother, because you are forking a "real" Git repo.

git fork git://git.apache.org/camel.git <TargetDirectory>

Bringing your modifications back to Apache is the same workflow as described before.

Drawback of this Apache Git repository is that it is a "mirror" with a day relay. So you are one day behind the community ...

Pull request at Github

There is also a Git repository at Github which you could fork. Then you work on a new feature branch and send a pull request. For granting the license you also should create a Jira issue with a reference to that pull request. One of the committers then could bring that changesets to the ASF codebase via his/her own local repository. After closing the Jira issue you have to close the pull request because we can't do that...

Same drawback here - it is one day behind ...

More resources

Git is not a brand new technology and therefore Camel is not the only ASF project thinking about using it. So here are some more resources you mind find useful:

http://wiki.apache.org/general/GitAtApache: Some basic notes about git@asf
http://git.apache.org/: List of mgit-mirrors at ASF
https://git-wip-us.apache.org/: More Git infos from Apache

Becoming a committer

Once you've got involved as above, we may well invite you to be a committer. See How do I become a committer for more details.

Using the issue tracker

Before you can raise an issue in the issue tracker you need to register with it. This is quick & painless.

If you want to have a go at fixing an issue you need to be in the list of activemq-developers on the issue tracker. To join the group, please mail the d...@camel.apache.org mail list with the email address you used to register with the issue tracker and we'll add you to the group.

Becomming a committer

The first step is contributing to the project; if you want to take that a step forward and become a fellow committer on the project then see the Committer Guide

Stop watching space | Change email notification preferences

View Online | View Changes | Add Comment

[CONF] Apache Camel > Contributing

Contributing