From 200a40b332420f94992eb39a6d0ea1cf1490ffc4 Mon Sep 17 00:00:00 2001 From: coreyg Date: Fri, 21 Nov 2014 09:30:19 +0000 Subject: Adding tuscany's website to their svn repo for svnpubsub git-svn-id: http://svn.us.apache.org/repos/asf/tuscany@1640879 13f79535-47bb-0310-9956-ffa450edef68 --- site/trunk/site-publish/developing-sdo-java.html | 282 +++++++++++++++++++++++ 1 file changed, 282 insertions(+) create mode 100644 site/trunk/site-publish/developing-sdo-java.html (limited to 'site/trunk/site-publish/developing-sdo-java.html') diff --git a/site/trunk/site-publish/developing-sdo-java.html b/site/trunk/site-publish/developing-sdo-java.html new file mode 100644 index 0000000000..6a768c89dd --- /dev/null +++ b/site/trunk/site-publish/developing-sdo-java.html @@ -0,0 +1,282 @@ + + + + + + + + + + + + + + + Apache Tuscany : Developing SDO Java + + + + + + + + + + + + + + + +
+ + + + +   + +
+ + +
+
+ + + + + + + + + +
+  Apache Tuscany > Home > SDO Overview > SDO Java > Developing SDO Java + + User List | Dev List | Issue Tracker   +
+ + + + + + + +
+ + +
+ +
+
+ + +
+
General
+

Home
+License
+Get Involved
+Found a Bug?

+
+ +
SDO Java
+

SDO Java Home
+FAQ
+Downloads
+Documentation
+Source Code

+
 +
How to get involved in development of Java SDO?
+

This document is the development guideline for SDO Java project.

+ + + +


+ 

+
+ +

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

+

+
+
+
+
+ + +
+ + + + + + website stats + +
+ Copyright � 2003-2012, The Apache Software Foundation  
+ Apache Tuscany and the Apache Tuscany project logo are trademarks of The Apache Software Foundation. +
+ + + + -- cgit v1.2.3