• Use javadoc on all methods.
• If you define an interface and then provide and implementation of this interface use @see tags to point Javadoc back to the interface method. You should then keep all your Javadoc defined in the interface so that it isn't duplicated in your implementation.
• Describe all return values (@returns), method parameters (@param) and Exceptions (@throws)
• If you define a new method make sure to include a package.html which defines what this package does.
• If you make a change to a method or class, please add yourself to the @author tags. Please also include your e-mail address.

Style Checker

A Java style checker, checkStyle, is part of the build process. This should aid in the development of readable code. Jetspeed currently works with version 2.4 of the checkStyle. For more information see http://checkstyle.sourceforge.net. Here is a list of rules currently enforced by the style checker: Unused imports should be removed '(' should be followed by whitespace ')' should be preceeded by whitespace Cast needs to be followed by whitespace '{' should be on a new line '}' should be alone on a line There should be no empty catch blocks Variable must match pattern '^[a-z][a-zA-Z0-9]*$' Line should be no longer than 130 characters ',' needs to be followed by whitespace '+' should be followed by whitespace

Syntax and Style Guide

Please use spaces within method parameter lists: Instead of: this.test(true,true,"test",true); please use: this.test(true, true, "test", true); Use of brackets. Some developers have personal a preference to how they place brackets within their source code: if (true) { //body } or if (true) { //body } Please choose whatever style you want for new files but you should maintain the existing style of source you wish to modify. If you have a method with multiple parameters, separate them across multiple lines. Instead of having a long list of parameters on one one line, break your parameter list across several lines: private final PortletSet getPortlets(Portlets portlets, RunData rundata, boolean application, boolean applicationsOnly) { } private final PortletSet getPortlets(Portlets portlets, RunData rundata, boolean application, boolean applicationsOnly) { }

Testing is a great way to detect and prevent bug. By automating the testing process, the test are easy to run and identify failures. Jetspeed uses the testing facilities built into Ant, primarily Cactus and JUnit.

Guidelines

The name of test class should start with Test and be located in the package it test. All new functionality should include appropriate testing. This can be JUnit tests, Cactus tests, or both. Fixes should also include the appropriate testing additions and/or changes to detect what is being fixed, i.e. modify the test to detect the problem then fix the problem. The updated test(s) should confirm you fixed the problem. Run the Required Tests after a cvs checkout, after a cvs update, and before a cvs commit. Run the appropriate tests the early and often.

The Test Suite

Required Tests The required tests are made up of Cactus and JUnit test used to insure working, and hopefully bug free, code. Command to run Test Description build unittest-all Runs all required unit tests build tests_tomcat_32 Runs all required Tomcat 3.x (JSP 1.1) tests build tests_tomcat_40 Runs all required Tomcat 4.x (JSP 1.2) tests Unit Test Groups These are unit tests grouped logically. In some case their is a testing hierarchy. In the case of unittest-security. It is composed of the security implementation test, i.e. unittest-security-registry and unittest-security-turbine. Below is just a sample of Unit Test Groups available Command to run Test Description build unittest General unittests. Long running test do not belong here build unittest-security General unittests of Jetspeed Security implementations. build tests_cache General unittests of caching subsystems.

Cactus

Cactus testing is used when rundata is required. The test usually involve generating a URL in beginTestName(). The URL is passed to a test, named testTestName(), running on a web server started by Cactus. The execution of Cactus test are dependent on the version of the servlet engine. Currently their are two place in build.xml to add Cactus test. Example of Cactus test can be found in org.apache.jetspeed.test.BasicSecurityTest and org.apache.jetspeed.template.TestJetspeedLink. Documentation for Cactus can be found at http://jakarta.apache.org/cactus

JUnit

JUnit testing is simpler the Cactus testing, in part because the do not require a web server. These test generally test small functional units, like reading a file into a data structure. Turbine services also be tested with JUnit test, see org.apache.jetspeed.services.registry.TestMarshallRegistry. Example of JUnit test can be found in org.apache.jetspeed.services.registry.TestMarshallRegistry and org.apache.jetspeed.template.TestJetspeedLinkFactory. Documentation for JUnit can be found at http://junit.org

Java Property file

Enter the property in the language propery file, org.apache.jetspeed.modules.localization.JetspeedProperty_ language.properties. All properties should be placed in the english, en, property file and any other language property files. When adding/changing properties, these properties should be added/changed in files for ALL languages. For example, if a property is added or updated, the property should be copied to all language property files with the English value. This will serve as a reminder to the maintainer that the property file needs to updated. CUSTOMIZER_REF_DEFAULTTITLE=Reference

Java Source Code

The following code will place the localized, based on the user's language, value into the variable title. import org.apache.turbine.services.localization.Localization; String title = Localization.getString("CUSTOMIZER_REF_DEFAULTTITLE");

Velocity

The following code will center the localized, based on the user's language, value on the resulting portlet. <center>$l10n.CUSTOMIZER_REF_DEFAULTTITLE</center>

In general logging should be kept to a minimum. Logging is very usefully for diagnosing and resolving problems. Error message should describe the error, and where practical the cause and suggested solutions.

Debug logging is intended for development and problem determination. It is not intended for use in a "normal" production environment. In part because of the resource, including CPU and disk space, required. So use Log.getLogger().isDebugEnabled() to determine if debug logging is enable before generating the debug message.

	if (Log.getLogger().isDebugEnabled()) { Log.debug("JetspeedRunDataService: accessing rundata " + m_runDataStore.get(Thread.currentThread()) + " for thread: " + Thread.currentThread()); }

• File structuring. Try to keep everything organized according to the current directory structure. For example do no put documentation within the ./src/java directory.
• Try not throw a basic java.lang.Exception. All Exceptions thrown within Jetspeed which describe an internal problem should extend org.apache.jetspeed.util.JetspeedException (see PortletException.java)