Contributing to the project
Where to begin
Subscribe to the development mailing list: junitpdfreport-develop.
Get the sources from cvs.
Instructions for configuring cvs, and a link to the cvs web browser are available here.
Try building the project from source.
The manual explains how to do this.
The Project's codebase is maintained in CVS (junitpdfreport.cvs.sourceforge.net).
Only Committers have write access to these repositories. Everyone has anonymous read access. More information on the SourceForge source code repositories is available here.
All Java Language source code in the repository must be written in conformance to the "Code Conventions for the Java Programming Language" as published by Sun.
All source code committed to the Project's repositories must be covered by the Common Public License V1.0 or contain a copyright and license that allows redistribution under the same conditions as the Common Public License V1.0.
Any code, document, or binary that is does not use the Common Public License V1.0 should not be committed to the project.
Any JAR committed to the Project's repositories must be licensed for redistribution. BSD and MPL style licenses are generally fine, but many Sun JARs do not permit redistribution.
In general, we don't want to maintain JAR files in cvs. Dependencies are documented on the home page.
Each of the Project's active source code repositories contain a file named STATUS which is used to keep track of the agenda and plans for work within that repository. The status file includes information about release plans, a summary of code changes committed since the last release, a list of proposed changes that are under discussion, brief notes about items that individual developers are working on or want discussion about, and anything else that may be useful to help the group track progress.
Simple patches to fix bugs can be committed then reviewed. With a commit-then-review process, the Committer is trusted to have a high degree of confidence in the change.
Doubtful changes, new features, and large scale overhauls need to be discussed before committing them into the repository. Any change that affects the semantics of an existing API function, the size of the program, configuration data formats, or other major areas must receive consensus approval before being committed.
Related changes should be committed as a group, or very closely together.
Half complete projects should never be committed to the main branch of a development repository. All code changes must be successfully compiled on the developer's platform before being committed. Also, any unit tests should also pass.
The current source code tree for a subproject should be capable of complete compilation at all times. However, it is sometimes impossible for a developer on one platform to avoid breaking some other platform when a change is committed.
If it is anticipated that a given change will break the build on some other platform, the committer must indicate that in the commit message.
A committed change must be reversed if it is vetoed by one of the voting members and the veto conditions cannot be immediately satisfied by the equivalent of a "bug fix" commit. The veto must be rescinded before the change can be included in any public release.
When a specific change to a product is proposed for discussion or voting on the appropriate development mailing list, or contributed as part of a bug report, it should be presented in the form of input to the patch command. When sent to the mailing list, the message should contain a Subject beginning with [PATCH] and a distinctive one-line summary in the subject corresponding to the action item for that patch.
The patch should be created by using the diff -u command from the original software file(s) to the modified software file(s). It is recommended that you submit patches against the latest version of the software in the source code repository in order to avoid conflicts. This will also ensure that you are not submitting a patch for a problem that has already been resolved.
cvs diff -u Main.java >> patchfile.txt
For CVS access on Win32, you can use WinCVS for a nice GUI or you can install Cygwin which will enable you to use the bash shell and also installs a lot of other utilities (such as diff and patch) that will turn your PC into a virtual Unix machine.
If you use WinCVS, move to [Admin] -> [Command Line] Menu and type:
cvs diff -u
at [Enter a cvs line command] input field ([Commandline Settings] Tab), while selecting the target directories or files, in order to create unified diffs. In other words, [Alt+A]+[Alt+C]+ [Alt+C] and type "cvs diff -u".
Also, by adding the full path name of WinCVS-Installed directory to
"path" environment variables, you can use "cvs diff" command on the checked-out directory (like cvs diff -u > patchfile.txt) recursively via MS-DOS command prompt.
All patches necessary to address an action item should be concatencated within a single patch message. If later modification to the patch proves
necessary, the entire new patch should be posted and not just the difference between the two patches.
If your email client line wraps the patch, consider placing the patch file up on a website and sending a message to the development list with the URL so that the developers with commit access can download the commit the patch file more easily. You can also add the patch as part of a bug report.
When a patch has been checked into the source code repository, the person who checked in the patch should send a message to the person who sent the patch in as well as the mailing list specifying that the patch has been checked in. The reason is that not everyone watches commit messages and it is helpful for others to know what has been checked in and when in order to help prevent people from applying the patch at the same time.
The release process is documented in the release charter.