Developer Guide

Development Environment

The following software prerequisites must be installed and in working order before building gridrus from source.

  • Java Software Development Kit 1.5 series: Java J2SE Software Development Kit 1.5.0_x. The SDK directory will be referred to as JAVA_HOME in this document.
  • Open Middleware Infrastructure Institute - Server 3.4.0: The OMII installation directory will be referred to as OMII_HOME in this document.
  • Open Middleware Infrastructure Institute - Client 3.4.0: The OMII client installation directory will be referred to as OMIICLIENT_HOME in this document.
  • Apache Ant 1.6+: Java based build tool. The directory where Ant is installed will be referred to as ANT_HOME in this document.

Preparation

The following procedure will setup the required environment variables and software tools for building gridrus

Checking-out gridrus from CVS

To access the CVS repository you will need to have a sourceforge account.

To gain write access, you need to be a member of the developer group. Please contact the lead developer for access.

To check out gridrus, type the following command in the directory where you like gridrus to be checked out. The gridrus-core directory you have checked out will be referred as GRIDRUS_HOME

$> setenv CVS_RSH ssh
$> cvs -d:ext:<USER>@gridrus.cvs.sourceforge.net:/cvsroot/gridrus co gridrus/gridrus

   or (a particular development version)

$> cvs -d:ext:<USER>@gridrus.cvs.sourceforge.net:/cvsroot/gridrus co -r <BRANCH_NAME> gridrus/gridrus

NOTE:

  • USER is your sourceforge username
  • BRANCH_NAME is the CVS branch you would like to use. Please see CVS Branches for the available branches.

Setting up Apache Ant

  • In order to perform JUnit tests in Ant, the <junit../> task has a dependency to the junit.jar library file. Copy the file from <GRIDRUS_HOME>/lib/ant/junit.jar to <ANT_HOME>/lib/.
  • To ensure Apache Ant is using the JDK of your choice, make sure the JAVA_HOME variable points to the directory of the JDK you would like to use.

Developing with gridrus

Source Directory Structure

The source distribution of gridrus-core has the following directory structure

.
|-- target                          ; maven output directory of a build
|   |-- classes                     ; java classes compiled from source
|   |-- dist                        ; contain different version of the binary distribution
|   |   `-- gridrus-x.x             ;
|   |       `-- gridrus             ; the directory containing the binary distribution
|   |                               ; (see next section)
|   |-- javagen                     ; temporary directory for dynamically generated classes
|   |-- javagen-nc                  ; temporary directory for dynamically generated sources
|   `-- surefire-reports            ; containing junit test reports
|-- dist
|   |-- client                      ; client binary distribution created by "build-client"
|   |-- server                      ; server binary distribution created by "build-server"
|-- src                             ; source code
|   |-- doc                         ; root of the documentation directory
|-- modules                         ; GridRUS sub-modules
|   |-- service                     ; service sub-module
|   |-- core                        ; core sub-module
|   `-- client                      ; client sub-module
|
|-- build.xml                       ; the main build file
`-- build.properties                ; the build configuration file
  • Java Source Code: All java source code should be added to the src/java directory following the java package naming requirement
  • Third Party Libraries (.jar files): should be added to the lib/third-party-name directory. A LICENCE file provided by the third-party must be added to that directory. Jar files in the lib/* directory will be added to the compilation classpath automatically.
  • Generated Classes: source code that is generated dynamically and require no change from the developer's part should not be checked into CVS. The generation process should be executed in the build.prebuild.xml Ant file, therefore included in the compilation. (read build.prebuild.xml for example)
  • Post Build: After all source-code is compiled and packaged, additional tasks can be put in the build.postbuild.xml to perform post-build process (such as packaging .war file)
  • The build/ directory contains the output of the build process. This directory SHOULD NEVER be checked into CVS. Some directories serve as places for staging file. The binary distribution can be found in build/dist/gridrus-*/gridrus/.
Binary Directory Structures
  • Server Distribution (dist/server)
    |-- docs                    ; this documentation
    |   |-- javadoc             ; the javadoc
    |   |-- ...                 ; other documentation
    |-- build.xml               ; server installation script
    `-- gridrus.war             ; deployable service archive
  • Client Distribution (dist/client)
    |-- bin                     ; executable, shell scripts, etc..
    |-- docs                    ; documentation
    |   |-- javadoc             ; the javadoc
    |   |-- ...                 ; other documentation
    `-- build.xml               ; client installation script
Compile and Test The <GRIDRUS_HOME>/build.xml is the primary 'make' file used by Ant to build the module and execute any junit tests. The build.xml file defines ant build targets. Read the build.xml file for more information. Here are some of the useful targets:
$> ant -projecthelp
Buildfile: build.xml

Main targets:

 build-all     build the server, client and documentation
 build-client  build the client
 build-doc     build the documentation
 build-server  build the server
 test          performs tests
 
  • To build gridrus client
    $> cd <GRIDRUS_HOME>
    $> ant build-client
  • To test gridrus server
    $> cd <GRIDRUS_HOME>
    $> ant test
  • Test output can be found in the GRIDRUS_HOME/build/test/ directory
Logging

Developers are encouraged to use the org.apache.commons.logging API for fine-grained control of verbosity (e.g. severe, warning, debug), format (e.g. minimal, timestamped) and output (e.g. stdout, file, socket) of logging messages instead of the System.out.println() approach. It is the preferred practice to associate a org.apache.commons.logging.Log with each class you create.

package mypackage;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;


public class MyClass {

    // the class logger. The name of the logger is the same as the fully-qualified
    // class name
    private static final Log sLog = LogFactory.getLog(MyClass.class);

    public void myMethod(){
        sLog.debug("this is a debug message");
        sLog.info("this is a informational message");
        sLog.warn("this is a warning message");
        sLog.error("this is a warning message");

        try {
            // critical work here...
        } catch (SomeException e){
            sLog.error("we have encountered an error", e);
        }
    }

}
            
Unit Testing
JUnit is a regression testing framework. It is a powerful and simple tool to unit test a piece of functionality or a class against a set of requirement.

Developers are encouraged to write JUnit TestCase for each class they have created, or at least for any well-defined piece of functionality. The gridrus build system will automatically execute all junit.framework.TestCase derived classes that has class name ending with *TestCase.java unless excluded in the build.xml file. A sample test case class looks like the following

package mypackage;

import junit.framework.TestCase;

public class MyClassTestCase extends TestCase {

        public MyClassTestCase(String args){
                super(args);
        }

        public void testMethodAWithNullParameter(){
                MyClass c = new MyClass();
                assertTrue(c.methodA(null));
        }

        public void testMethodAWithStringParameter(){
                MyClass c = new MyClass();
                assertTrue(c.methodA("some string"));
        }

}

Each method in the TestCase that starts with testXYZ() defines a test case. junit.framework.TestCase provides a collection of assertXYZ() method to assert truth of expected behaviour of the class you are testing. If any of the assert statement is failed, the test will fail. Test output can be found in the build/test/TEST-name-of-test-class.

NOTE

  • Coding Convention: The test method name is usually named after the functionality or method you are trying to test. It should also reflect the specific elements you are testing (e.g. handling of null parameter, etc.). The test case should also live in the test directory inside the package of the class you are trying to test.
Documentation
Manuals

GridRUS uses Maven APT to generate documentation from presentation neutral XML sources.

To preview the document while authoring

$> cd ${GRIDRUS_HOME}/
$> mvn site
Coding Guidelines
Java Coding Guideline

Developers are encouraged to adopt the Java coding convention to ensure consistency in the codebase. The following guidelines should be observed

Java packages in gridrus should start with org.icenigrid.gridrus.function. function is a self-contained functionality provided as part of gridrus, such as "webservice", "core", etc..

Dynamically generated classes should not be in the src/java directory. They should be created at build time. These classes are likely to be changed when the schema or WSDL changes. It is difficult to manage these classes if they are version-controlled.

Implementation classes that implements a well-defined interface should live in an impl package in the package of the API classes. The Factory/Builder pattern should be used to allow pluggable implementation. The core implementation of GridRUS uses Apache Hivemind to provider inversion of control styled dynamic composition of runtime objects.

Code should be documented using the Javadoc standard.

XML Coding Guideline

This section describes guideline for authoring and processing WSDL and XSD schemas.

XML Namespace URIs used in gridrus follows W3Cs naming convention.

http://www.icenigrid.org/<year>/<month>/<context>/<sub-context>
  • <year>: the year the identified document is defined
  • <month>: the month of the year the identified document is defined
  • <context>: the context in which this document is used
  • <sub-context>: the sub-context in which this document is used

    Example URIs

    http://www.icenigrid.org/2004/11/service/gridrus

    The DOM4j library is used throughout GridRUS for parsing and constructing XML document.