General Guide

Welcome to the Tuscany SDO Java subproject. 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 SDO sub-project aims to provide uniform access to data from heterogeneous sources which could be XML, RDB, POJO, SOAP, etc.
• Tuscany Java SDO is not just a reference implementation. We encourage innovation based on the tenets of SDO. A lot of work we do provides feedback to the specifications.
• SDO provides both a static (or strongly typed) programming model and a dynamic (or loosely typed) programming model. This provides a simple programming model without sacrificing the dynamic model needed by tools and frameworks.
• It supports a disconnected model and provides Meta-data for easy introspection of data types.

Getting Source code and Setting Development Environment

The Java SDO project Subversion repository is located at https://svn.apache.org/repos/asf/incubator/tuscany/java/sdo.
The repository 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 code from Subversion

Use the command as follows (note that it uses http scheme so if you're a committer change it to https):

svn checkout http://svn.apache.org/repos/asf/incubator/tuscany/java/sdo

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've entered it, it will remember it for you. Note this is the password you configured with svnpasswd not your shell or other password.

For more details check Getting Source. Also for setup details check Establishing a Development Environment. Reference the code structure at SDO Project Code Structure.

Coding Guidelines

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

• The basic coding style used is described at Sun Java coding standards but the main thing is to be consistent with the existing code you're updating, so for example, if you're updating a method that uses the braces on the same line style don't add code with the hanging braces style.

• Always include the Apache License Headers on all files (both source code files and resource files such as xml documents)

• Include a descriptive log message for check-ins, for example "fixed such and such problem".

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.

Testing

Tuscany uses plain junit test cases to perform unit and integration testing. You can check Test Cases for some examples.

Note that we use surefire maven plugin to run the unit and integration tests, and in most cases, they are configured to match a **/*TestCase.java file name pattern. Because of this, if your test case has a different file name pattern, you might execute it from your IDE of choice, but the maven build won't execute the test.

Maven Build Structure

We use the term Module to refer to the leaf of maven tree.

• All poms will use the pom from the parent folder as parent pom
• Group id: org.apache.tuscany.sdo
• Version of our modules will be specified once in java/sdo/pom.xml, child poms don't need to specify a version as they get it from their parent
• pom names begin Apache Tuscany SDO
• Eclipse projects are generated for all built modules using mvn -Peclipse eclipse:eclipse

Reporting issues and providing patches

You are very welcome to help us develop Tuscany SDO Java. You may have ideas that you want to pursue yourself or you may wish to pitch in with the design, coding and documentation. If it's the first of these two then please put forward your suggestions on the development mailing list. If it's the latter, then feel free to ask on the mailing list or browse the issue tracking.

Reporting an Issue or Asking For New Features

Please use ApacheJIRA system to report bugs or request new features. First time users need to create a login.

Search the existing JIRAs to see if what you want to create is already there. If not, create a new one. Make sure JIRAs are categorized correctly using JIRA categories and are created under the correct component area. Please include as much information as possible in your JIRA to help resolve the issue quicker. This can include version of the software used, platforms running on, steps to reproduce, test case, details of your requirement or even a patch if you have one.

Submitting a Patch

Please follow the steps below to create a patch. It will be reviewed and committed by a committer in the project.

• Perform a full build with all tests enabled for the module the fix is for. Specific build procedures vary by sub-project.
• Confirm that the problem is fixed and include a test case where possible to help the person who is applying the patch to verify the fix.
• Generate the patch using svn diff File > patchfile
• Try to give your patch files meaningful names, including the JIRA number
• Add your patch file as an attachment to the associated JIRA issue
  • Clicking on the 'Patch Available' box in the screen where the patch is being submitted will help identify available patches quicker.

How do I get my JIRAs into a release?

You can always propose a release and drive the release with the content that you want. Another way to get a JIRA into a release is by providing a patch or working with other community members (volunteers) to help you get the problem fixed. You can also help by providing test cases.

Each release is managed by a release manager. Make sure that the Release Manager is aware of why a fix to a JIRA is important to your business. In general, the best attempt is made to include as many JIRAs as possible depending on the level of community help. The voting mechanism in the JIRA system can be used to raise the importance of a JIRA to the attention of the release manager. Adding comments in the JIRA would help the release manager understand why a JIRA is important to include in a given release.

How is a release done?

Anyone can volunteer to be a release manager and drive a release. Based on Apache guidelines, a release requires at least three PMC +1 votes and more +1s than -1s. A release can not be vetoed so a -1 does not block a release. The steps for how to create a Tuscany release are documented here