Page History

{panel:title= How to get involved in development of Java SCA? |borderStyle=solid|borderColor=#6699ff|titleBGColor=#D5EFFF|bgColor=#ffffff}
*this page needs to be updated with the latest top/down build info and testing mechanism. Thanks* :-)
* [General Guide|#General Guide]
* [Getting Source|#Getting Source]
* [Getting Setup For Development|#Getting Setup]
** Prerequisit
** Building
* [Coding Guidelines|#Coding Guidelines]
* [Testing|#Testing]
* [Maven Build Structure|#Maven Build Structure]


\\
 
{panel}
{section}
{section}

h3. {anchor:General Guide}{color:#0099cc}General Guide{color}

Welcome to the Tuscany SCA Java subproject project. We look forward to your participation and try to help you get on board. Feel free to ask your questions on the mailing list.

Here are some general guidelines we use in this project.
* Java SCA sub-project aims to provide enterprise-grade service infrastructure based on SCA.
* 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.
* The Java SCA infrastructure should provide flexibility and choice. It should not dictate programming models but support many.
* The Java SCA infrastructure is very modularized and is designed to be highly extensible so users can customize it to fit their needs.

h3. {anchor:Getting Source}{color:#0099cc}Getting Source{color}

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.

h4. Checking out code from Subversion

Use a command like:
{code}
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/sca
{code}
j4. 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}
svn commit
{code}
If Subversion can't figure out your username, you can tell it explicitly:
{code}
svn --username <name> commit
{code}
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.

h3. {anchor:Getting Setup}{color:#0099cc}Getting Setup For Development{color}


h4. Prerequisites

Java SCA requires the following:
* [JDK 5.0\+ (J2SE 1.5.0+)|http://java.sun.com/j2se/1.5.0]
* [Apache Maven (2.0.4+)|http://maven.apache.org/]
* [Subversion (1.2+)|http://subversion.tigris.org/]

h4. 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 individual modules can be built separately or build with top-down build.

h4. top-down build
*recommended approach*

Check out all of the java source code.
{code}
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java
{code}
Building the SCA source code is simple
{code}
cd java/sca
mvn
{code}
It should work even if you start with an empty Maven local repository, and it should always work. 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.

(on) 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.

h4. Building individual modules

(?) This section needs to be updated. We still have the ability to build modules.

To build individual modules, please see the specific instructions for each top-level 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:
{code}
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/kernel
{code}
To build kernel, do:
{code}
mvn
{code}
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:
{code}
svn checkout https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime
{code}
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.

h3. {anchor:Coding Guidelines}{color:#0099cc}Coding Guidelines{color}

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}
@version $Rev$ $Date$
{code}
* ItPlease isattempt highlyto recommended thataccompanied code checked in be accompanied bywith at least unit tests or verify verifiedit by existing unit tests. Integrationbefore testssubmitting whena appropriatepatch areor alsochecking helpfulin.

* 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}
mvn clean
mvn -o -Psourcecheck
{code}
* Please do not perform a checkin using an IDE as doing so is frequently problematic.

* Include a descriptive log message for checkins, for example "fixed such and such problem".

h4. Naming conventions to increase consistency

*Folder Names:* Please use all lowercases and dashes in folder names (like in the jar names)
- Maven artifact id = tuscany-<folder name>

*Package names:* Package names within modules should include the module name so that source code can be located in the source tree easily. So, for example, java/sca/module/implementation-java would be in package structure org.apache.tuscany.implementation.java.\*

h3. {anchor:Testing}{color:#0099cc}Testing{color}

(?) This section seems to be outdated since integration tests can also be done without maven integration test plugin

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|http://www.martinfowler.com/articles/continuousIntegration.html]

We have found [EasyMock|http://www.easymock.org/] extremely useful for unit testing and have standardized on it.

When writing integration tests, use the [Maven Integration Test Plugin|Maven Plugins]

h3. {anchor:Maven Build Structure}{color:#0099cc}Maven Build Structure{color}

_We use the term Module to refer to the leaf of maven tree._
* 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

h4. Adding a new module and not ready to integrate?

'work-in-progress' modules can be worked on in the same source tree and yet not break the top-down build. You can do this by not listing your module(s) in java/sca/modules/pom.xml.

{HTMLcomment:hidden}{children:sort=creation}{HTMLcomment}