| Checkin Procedures | ||
|---|---|---|
 | Chapter 6. Development Procedures |  |
| Checkin Procedures | ||
|---|---|---|
| | Chapter 6. Development Procedures | |
You should always follow these procedures when checking in code:
Run JUnit tests (ant junit) before doing a checkin.
Build the Javadoc (ant javadoc) to ensure there are no errors introduced.
Add a Bugzilla bug or a feature request describing the change.
When checking code in, use the Bugzilla bug id as the checkin comment.
In addition, update the Tapestry release notes, the file web/new.html,
to identify the feature request.
If you are adding new code, please make sure that the code contains:
The Apache license in a comment block at the beginning.
The $Id$ symbol as described above.
Be very careful when checking files in that they are checked in with the correct
keyword substitution type.
Files should be either binary or text; text should be checked in with keyword
expansion turned on (this is the -kkv option).
When new files are added using Eclipse, it must decide whether they are binary or text. Eclipse always assumes binary unless specifically informed that a file is text. Use the Team preferences panel to set this.
Finally, if major changes are enacted, it is good to ensure that the framework continues to be compatible with the API versions declared in the User Guide. This can be verified by performing the following actions:
Compile the framework using Java 1.2.2.
(e.g. by setting JAVA_HOME and running ant)
Run the unit tests using both Java 1.3.x and 1.4.x
(e.g. by setting JAVA_HOME and running 'ant junit').
Running the unit tests under 1.3.x would require adding
the Xerces libraries to the classpath
(e.g. to lib/ext).
Compile with Java Servlet API 2.3 and run the unit tests
using Java Servlet API 2.2
(e.g. by compiling, then pointing the servlet.jar setting in
the config/build.properties file to the
Java Servlet API 2.2 library and running 'ant junit')
| |  | |
| Component Documentation |  | Creating Examples |
