Firstly, thanks for your interest in contributing! I hope that this will be a pleasant experience for you, and that you will return to continue contributing.
Please visit our Get Involved page for more information on how to contribute.
This project and everyone participating in it are governed by the Apache software Foundation's Code of Conduct. By participating, you are expected to adhere to this code. If you are aware of unacceptable behavior, please visit the Reporting Guidelines page and follow the instructions there.
Most of the contributions that we receive are code contributions, but you can also contribute to the documentation, wiki, etc., or simply report solid bugs for us to fix.
Please review our guide on how to submit a bug report. This page also has links to other resources to assist you.
Apache Tomcat project uses POEditor for managing the localization files. Please see more at https://cwiki.apache.org/confluence/x/vIPzBQ
Unsure where to begin contributing to Tomcat? You can start by taking a look at the issues marked 'Beginner', link below. Please note that the Beginner keyword is pretty new to the project, so if there aren't any issues in the filter feel free to ask on the dev list.
- Beginner issues - issues which should only require a few lines of code, and a test or two to resolve.
The list above shows all bugs that are marked 'Beginner' and are open in the currently supported Tomcat versions (7, 8.5, and 9).
If you prefer C over Java, you may also take a look at the tomcat-native and Tomcat Connectors products in Bugzilla.
Excited yet? This section will guide you through providing a patch to the committers of the project for review and acceptance.
You can provide a patch in one of the following ways (in order of preference):
- GitHub Pull Request
- Patch attachment to the Bugzilla issue
- Email the patch to the developer list. This is not preferred, but if no bug is associated with the patch, or you would like a developer review, an email may be appropriate.
Now that you've chosen how you want to submit a patch, you need to get the source code.
This method works if you want to submit a patch via email, but the difference in using the sources distribution and a VCS is that you have to manually generate the patch file by using diff. If this is what you want, you can download the sources from the "Source Code Distributions" section of the Download Page. There is one such page for every major Tomcat version:
If you have chosen to attach a patch to the Bugzilla issue (or email one), then you'll need to download the sources as noted above, make your desired changes and then manually generate your patch using diff (or any other tool).
To submit a GitHub Pull Request you'll need to fork the repository, clone your fork to do the work:
$ git clone https://github.com/$USERNAME/tomcat.git
and then push your changes, and submit a Pull Request via the GitHub UI.
After you've chosen your method of submission, retrieved the sources, and fixed the issue it's time to submit your work. At this point, just follow the method of submission you chose earlier.
- GitHub PR - after resolving the issue in your local fork and pushing to your copy of the repository, open a GitHub PR for review.
- Bugzilla attachment - attach the patch to the Bugzilla issue
- Email - again, not preferred, but you may send an email to the developer list with a patch attached for review.
It may take a while for committers to review. Please be patient during this time as all committers are volunteers on the project. If a significant amount of time has lapsed since your submission, such as a couple of months, feel free to either update your BZ, PR, or email the dev list with a message to bump your issue. Sometimes things get lost in all the work and we need a reminder 😄
Special IDE support for Eclipse, IntelliJ IDEA and NetBeans is provided through special ant targets:
ant ide-eclipse
ant ide-intellij
ant ide-netbeans
Just execute the ant target for your IDE after checking out the sources to set up the appropriate configuration files. Also make sure to re-execute the target after switching branches or after pulling upstream changes in order to keep your IDE configurations in sync.
Apache Tomcat has very loosely defined coding conventions, but the following guidelines will be useful:
- Use spaces for indenting, not tabs
- 120 char line width for Java source, 80 char line width for documentation source (.txt, .xml)
- Java source: { at end of line, 4 space indents
- XML source: 2 space indents
Have you reviewed this guide and found it lacking? Or are you confused about some particular step? If so, please let us know! Or better yet, submit a PR to address the issue 😉