How to Contribute to the Documentation

print-friendly version

Introduction

This document describes how you can easily contribute to the documentation. I'm going to try to make it easy for everyone to help out with the documentation of Tomcat, more specifically the documentation for the connectors. This is written from a windows user perspective as I believe they will most benefit from it. For people using Unix it should be easy for them to apply these steps. Just substitute Unix sytax where needed.

The documentation is produced using xml with xsl style sheets. This effectivly seperates the content of the documents from the style, so all that contributers need to worry about the content. It is much easier to use than html.

It's all really quite simple. Here is what you will need:

• A recent version of Ant
• The source code for the connectors from cvs
• Any ascii text editor

Getting Started Step by Step

After you get these tools they are simple to set up.

STEP 1. Get Ant

Install Ant . The only advice I have is to choose a simple installation path. Now set an environment variable for ANT_HOME, and then add the location of the Ant/bin directory to your PATH variable. Consult your Operating system documentation for information on how to do this. When you are finished verify that you can run ant from the command line.

Ant is used to build the documentation, among other things, and it must be able to see a file called build.xml . This file is located in the CVS_HOME\jakarta-tomcat-connectors\jk directory. In the build.xml file there is a target named docs that will be used to build the docs.

STEP 2. Get the sources

Get the sources for jakarta-tomcat-connectors from the CVS repository. If you'll be editing from a windows platform you will need a windows cvs client. There are several available. I like cygwin . During the install open the developer group and click on cvs. Unix users should install the CVS client of their choice, if they don't already have one.

You are ready to download the sources now. Change directory to the location where you want your repository to be, and run the following commands to download the sources for the first time. For simplicity we will call this your CVS_HOME. Mine is located in C:\build.

Login to the repository and then give the cvs password anoncvs .

When your prompt comes back you are logged in. Now run the following command to checkout the sources for the first time. You should only need to do this once.

You should now be watching all the downloads come in. Now that you have the sources on your machine the hard part if over. From now on, to update your sources all you have to do is cd into any directory in your repository and run cvs update

STEP 3. Test your build environment

Open a command prompt window and cd to the directory where you downloaded the source. Now cd into the jk directory so Ant can see the build.xml file and, from a command prompt, run the following:

You should see the ant compiler messages scrolling by rapidly and then stop with the following:

All the xml files present in the xdocs directory structure were transformed to html and copied to the CVS_HOME\jk\docs directory. Open one of the html files in your browser and see how it looks.

STEP 4. The editing process.

I find it easier to use two windows while doing my updates. One I call my build window. I keep this one in the CVS_HOME\jk directory and I only run two commands in this window:

My second window I call my edit window and I keep that one in the CVS_HOME\jk\xdocs directory where I'm doing my edits, diffs, and cvs updates.

Before you start editing you should always update your local repository to prevent conflicts.

Now that your repository is up to date you can begin editing. Find something in the documentation to edit. When you find somethng remember the name of the file. In your edit window find and edit the xml source file with the same name. After you are done return to the build window, and in the CVS_HOME\jk directory run:

This will delete all the previous html files and make the area ready for updated material. Now to make fresh documents that incorporate your changes run:

Use your browser to view the edits you just made, they will be in the CVS_HOME\jk\build\docs sub-tree. If it looks good and is ready to go, all that is left to do is to create a patch and submit it.

STEP 5. Creating a patch and submitting it.

From your edit window cd into the directory that contains the xml file you are working on, and run the cvs update command. For example, to produce a unified diff of the index.xml file and call it patch.txt, you would cd into the directory containing the index.xml file and:

Now that you have your patch you are ready to send it in.

Patches to the documentation are handled just like a bug report. You should submit your patches to http://issues.apache.org/bugzilla/ and include a good one line subject. If this is your first time to use the bug database then you should read http://issues.apach e.org/bugzilla/bugwritinghelp.html. You will need to create a user account. At the web site paste your patch into the web form and don't forget to describe what it is your patch is for. Sooner or later a someone with commit privileges will review your suggestion.

CVS Basics

After you have checked out the sources the first time it is much easier to use CVS. You can cd into any directory of the repository and run cvs update -dP to get the latest sources for that directory. For editing purposes you should always update your repository before you start editing to reduce conflicts.

You will need to run cvs diff to generate patches for submission. Again cd into the directory containing the file you are editing and run cvs diff -u name_of_the_file_you_edited patch.txt to generate a patch for submission. The -u is the flag for a unified diff which is the prefered type.

Pay attention to the terminal window during the update.

Lines begining with a P mean the local copy was patched to update it to the current version in the master repository.

Lines begining with a M mean your local copy is different from the master copy, and the changes were successfully merged into your copy.

Lines begining with a C mean there was a conflict in merging the changes and you need to review the file and merge the changes manually. Search for >>>> and merge the changes.

Lines begining with a ? indicate files that reside on your local system which are not part of the repository. You will normally see this when you are creating new files for submission.

Guides and Resources

A little help to get you if you need it

• XML Beginner's Guide
• Bugzilla
• Bugzilla Bug Writing Guide
• Ant
• CVS Home
• JK Docs CVS