THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
General
Development
Subversion Access
The Java SCA project Subversion repository is located at https://svn.apache.org/repos/asf/incubator/tuscany/java/sca.
The respository can also be viewed online at http://svn.apache.org/viewvc/incubator/tuscany/java/
Anyone can check code out of Subversion. You only need to specify a username and password in order to update the Subversion repository, and only Tuscany committers have the permissions to do so.
Checking out from Subversion
Use a command like:
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/sca
Committing Changes to Subversion
Any Tuscany committer should have a shell account on svn.apache.org. Before you can commit, you'll need to set a Subversion password for yourself. To do that, log in to svn.apache.org and run the command svnpasswd.
Once your password is set, you can use a command like this to commit:
svn commit
If Subversion can't figure out your username, you can tell it explicitly:
svn --username <name> commit
Subversion will prompt you for a password, and once you enter it once, it will remember it for you. Note this is the password you configured with svnpasswd, not your shell or other password.
Getting Setup for Development
Prerequisites
Java SCA requires the following:
Build tree structure
The build tree is designed to facilitate modular development and releases. Maven modules are grouped by how they are released under an hierarchy. For example, all kernel-related modules are grouped under the 'kernel' module. The build tree contains the following 'top-level' modules:
kernel
Contains the modules that make up the Java SCA foundation, including:
- api - Contains the Java SCA proprietary programming model apis
- host_api - Contains APIs for interacting with the kernel
- spi - Defines kernel extension points. Includes interfaces and abstract extension classes.
- core - The kernel implementation
Kernel may be checked out and built independently from the other modules such as extensions.
To checkout kernel, do:
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/kernel
To build kernel, do:
mvn
Note that mvn -o may be used once all kernel dependencies have been downloaded
runtime
Contains modules for deploying Java SCA to various runtimes, e.g. in a Servlet Container or as a standalone runtime:
- itest - modules for embedding Java SCA in Maven as an iTest Plugin. Used for integration testing.
- standalone - modules for deploying Java SCA as a standalone container
- services - various runtime services such as JMX
- webapp - modules for embedding Java SCA in a Servlet container
To checkout runtime, do:
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime
The runtime modules may be built together or indepdently as sub-modules using the mvn command.
extensions
Contains kernel extensions such as bindings for transport protocols, component implementation types to enable the use of alternatice programming models, etc. Each extension sub-module builds independently.
services
Contains kernel extensions that provide specific services such as persistence for core runtime operations. Each sub-module builds independently.
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 -Pcheckstyle
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.
When writing integration tests, use the Maven Plugins