The Java SCA sub-project aims to provide enterprise-grade service infrastructure based on SCA. Some of our principles include:
- Tuscany SCA is not just a reference implementation. We encourage innovation based on the tenets of SCA. A lot of work we do provides feedback to the specifications.
- We build runtimes that are distributed under the Apache Software License.
- We believe developing highly scalable service-based systems should be easier than it currently is.
- We believe in providing users with flexibility and choice. We do not dictate programming models but support many. Our runtimes are designed to be highly extensible so users may customize them to fit their needs.
- We provide frequent releases of our software so users can experience the newest features and have access to the latest bug fixes.
For those looking at or developing the Tuscany Java SCA source code this page provides some description of the code structure and associated conventions that are used during development.
(110407) This is an initial set of information derived from recent mail list traffic and will change as the latest reorg settles down
.
Getting the Source - 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:
Code Block |
---|
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:
Code Block |
---|
svn commit
|
If Subversion can't figure out your username, you can tell it explicitly:
Code Block |
---|
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:
Some Definitions
Module - we use the term module to refer to a leaf of the maven build tree. I.e a directory containing source code and resources that will be compiled to a releasable artifatct, a jar file.
...
Source and Build Structure
Looking at the source code for Java SCA you will see the following directory structure.
...
No Format |
---|
java/ pom/parent/pom.xml ... sca/ pom.xml - The maven pom that builds all of the releasable Tuscany Java SCA modules contrib/ - A temporary direcoty that ... holds modules not doc currently being developed or targetted ... for a itestrelease pom...xml doc/ - bindings Tuscany Java SCA documentation that exceptions will be included with the specrelease ... modules/itest/ - Integration tests that test system performace using combinations of Tuscan Java features pom.xml assembly... modules/ - A binding-axis2 flat direcory structure holding all contribution of the separate modules that core make up Tuscany Java SCA. databinding discovery-jmspom.xml federation... samples/ http-jetty Tuscany Java SCA samples idl-java which show how to use impl-java the various features of ... samples/the software build.xml <-- Samples build with Ant as well as Maven - TBD pom.xml calculator supplychain bigbank helloworld ... |
...
...
|
Naming Conventions
- Use all lowercases and dashes in folder names (like in the jar names)
- Maven artifact id = tuscany-<folder name>
- Package names within modules should include the module name so that source code can be located in the source tree easily. So, for example, the module
Code Block |
---|
java/sca/module/implementation-java
|
contains code in the package structure
Code Block |
---|
org.apache.tuscany.implementation.java.*
|
Module Location
If people want to work on some new modules that won't be part of the
next release and are not included in the top-down build, that's fine, we can
just avoid listing these modules in java/sca/modules/pom.xml. So, they
can be there in the same source tree but they won't break the release
top-down build, and they won't have to be building at all times.
Maven Build Structure
- sca/pom.xml's parent will be pom/parent/pom.xml
- Other poms will use the pom from the parent folder as parent pom
- Group ids:
org.apache.tuscany.sca ,
org.apache.tuscany.sca.samples,
org.apache.tuscan.sca.itest - Version of our modules will be specified once in java/sca/pom.xml,
child poms don't need specify a version as they get it from their parent - pom names begin Apache Tuscany SCA
- Eclipse projects are generated for all built modules using mvn -Peclipse eclipse:eclipse
Naming Conventions
- Use all lowercases and dashes in folder names (like in the jar names)
- Maven artifact id = tuscany-<folder name>
- ???
Module Status
If people want to work on some new modules that won't be part of the
next release and not included in the top-down build, that's fine, we can
just avoid listing these modules in java/sca/modules/pom.xml. So, they
can be there in the same source tree but they won't break the release
top-down build, and they won't have to be building at all times.
Building
Building From The Source
First of all check out all of the java source code.
Code Block |
---|
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java
|
Building the SCA source code is simple
Code Block |
---|
cd java/sca
mvn
|
Simple... cd java/sca, then mvn. 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:
Code Block |
---|
@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:
Code Block |
---|
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.
When writing integration tests, use the Maven Integration Test Plugin it's the least we can do
to be nice to our community of developers and users to avoid breaking
them all the time.