<?xml version="1.0" encoding="UTF-8"?>
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<title>Contributing to Checkstyle</title>
<link rel="stylesheet" type="text/css" href="mystyle.css"/>
<!-- The header -->
<table border="0" width="100%" summary="header layout">
<h1>Contributing to Checkstyle</h1>
<img src="logo.png" alt="Checkstyle Logo"/>
<!-- content -->
<table border="0" width="100%" cellpadding="5" summary="body layout">
<td class="menu" valign="top">
<td class="content" valign="top" align="left">
Hey, good to see you on this page. It means that you are
considering a contribution of your own work to the Checkstyle
project. We welcome anything: bugfixes, new check modules, unit
tests, documentation improvements, build process simplification,
This document assumes you are working with the CVS version of
checkstyle and that you are familiar with some standard
development tools (<a href="http://www.cvshome.org">CVS</a>,
<a href="http://ant.apache.org">Ant</a>, <a
The developer team of checkstyle is really a lazy bunch of
people. We try to avoid work as best as we can, but most of all
we try to avoid working on bugs that are reported by end users.
To that end, we use a set of development tools that ensure that the
quality of our code is kept at a fairly high level. Like most projects
today, we use JUnit to test our code. However we do take this one
step further and measure the coverage of our unit tests using
<a href="http://www.thecortex.net/clover">Clover</a>. This means it
is not sufficient to pass all tests, but the tests should ideally
execute each line in the code. The most recent Clover report is
available <a href="http://checkstyle.sourceforge.net/clover_html/">here</a>.
Besides using unit testing, we obviously also use checkstyle to check
it's own code.
We have the build target <span class="code">gump</span> in our
Ant buildfile that builds checkstyle, executes all tests,
and runs checkstyle on it's own code.
That target should pass without errors.
If you add new end user features, remember to document them.
<h2>Submitting your contribution</h2>
Once you have made sure that your changes pass the gump target,
and everthing is documented, you are ready to submit your work.
If you have created new files, put them in a tgz file (or zip if you
are on Windows). If you have changed existing files, create a unified
diff using CVS. To do that, open a command line, cd to the home
directory of checkstyle (where build.xml is located) and execute
<span class="code">cvs diff -u > mychanges.patch</span>.
Create a new item in our
<a href="http://sourceforge.net/tracker/?group_id=29721&atid=397080">patch tracker</a>
and add the tgz/zip/patch files you created.
Make sure the text in the tracker explains the purpose of your contribution.
When you create a tracker entry, a notification email about your contribution
will automatically be sent to the developer mailing list.
Be prepared to answer questions and do some polishing work.
We are not only lazy but at times we are also busy with our day jobs.
This means that you might not always get an immediate answer. You are
not being ignored, and we value your work - we might just be too busy
to review your code, especially if it is a bit complex. If you don't
get a response within two weeks, feel free to send a reminder email about
your tracker item.
<div><a href="index.html">Back to the Checkstyle Home Page</a></div>
<p class="copyright">Copyright © 2002-2004 Oliver Burn. All rights Reserved.</p>