Page History

...

It should work even if you start with an empty Maven local repository, and it should always work. Build breaks should be avoided or get fixed quickly. This assumes that maven is able to retrieve a SNAPSHOT version of SDO (and of course the rest of software that SCA depends on) as we haven't built anything other than SCA here.

Coding Standards

There are a few simple guidelines when developing for JAVA SCA:

• Formatting standards are defined by the .checkstyle and .pmd configurations in the source repository. Please be sure to check code is formatted properly before doing a checkin (see below). If you are unfamiliar with Checkstyle or PMD, please see http://checkstyle.sourceforge.net/ and http://pmd.sourceforge.net/. Consistent formatting makes it easier for others to follow and allows diffs to work properly.

• Always include the Apache License Headers on all files and the following version tag:

@version $Rev$ $Date$

• It is expected that code checked in be accompanied by at least unit tests or verified by existing unit tests. Integration tests when appropriate are also helpful.

• Do not checkin IDE-specific resources such as project files.

• Prior to check-in, perform a clean build and run the complete battery of unit tests for the current module from the command line with Checkstyle enabled, as in:

mvn clean
mvn -o -Psourcecheck

• Please do not perform a checkin using an IDE as doing so is frequently problematic.

• Include a descriptive log message for checkins, i.e. not, "fixed some stuff".

Testing Standards

It is expected checkins always be accompanied by unit test and integration tests when appropriate. Unit tests should verify specific behavior relating to a single class or small set of related classes; intergation tests verify code paths across subsystems. Testcases should be documented and clearly indicate what they verify. Also, avoid things that may cause side-effects when possible such as access of external resources.

We encourage and follow continuous integration. Martin Fowler has a concise write-up here

We have found EasyMock extremely useful for unit testing and have standardized on it.

There can be occasional problems downloading artifacts from remote Maven repositories so if mvn fails with network related sounding messages sometimes just trying again can fix the problem.

Coding style and Testing

Tuscany has some basic coding standards - use spaces not tabs, keep a reasonable line length, and include enough comments in the code. Tests are good, both unit and functional testing is encouraged. When modifying existing code try to use the style already in place or if necessary reformat the whole file so the style is consistent.

The ASF has some requirements on the license header that should be included in most files, for details see http://www.apache.org/legal/src-headers.html.

In the Tuscany SVN there is a folder tuscany/java/etc which contains various templates that can be used to configure your development environment, for example, codestyle template files which can be imported into the Eclipse or IDEA IDE's. Some Tuscany modules are set up to use the Maven Checkstyle facility which may be run using the Maven -Psourcecheck option.When writing integration tests, use the Maven Integration Test Plugin