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 not be followed by whitespace
• ')' should not 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
• '.*' form of import should be avoided

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) {
        }

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

The required tests are made up of Cactus and JUnit test used to insure working, and hopefully bug free, code.

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

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>