development/guidelines.mdtext

Title: Coding guidelines

<a name="BuildingAries-CodeStyle"></a>
# Code Style

There are not yet complete code formatters and checkstyle rules for aries. In the mean time you can set these rules.

* 4 spaces instead of tabs
* Line width 130 characters

<a name="MavenbestpracticeinAries-Assembledbestpracticenotes"></a>
# Maven best practice in Aries development

<a name="MavenbestpracticeinAries-Overallstructure"></a>
### Overall structure

The Aries project is a collection of loosely couple bundles, therefore
it must be possible to build each bundle on its own. This implies:

1. A parent pom that isn't at the root of the SVN trunk.
1. Each bundle has enough pom info so that it can be released
independently.
1. parent/default-parent has dependency management for basic osgi-dependencies that
all projects are almost certain to use (this includes PAX dependencies for
testing).
1. Each bundle has legal files in its checkout root.
1. Each bundle has an SCM element in its top level pom.
1. Bundles do not (except samples) have sub-modules.


<a name="MavenbestpracticeinAries-Goodpracticeinthepom"></a>
### Good practice in the pom

1. Alphabetic ordering in dependency management is helpful
1. Include a brief description of the project
1. Commenting in platform dependencies, see samples assembly projects.
1. Use ${project.version} _not_ ${version} for Maven 3 compatibility.

<a name="MavenbestpracticeinAries-GroupandArtifactnames"></a>
### Group and Artifact names 
1. The Bundle Symbolic Name is explicitly set to the Maven artifactId. For
projects which deliver bundles, the artifactID will therefore completely
describe the jar and must begin org.apache.aries.\{subproject\}. For
projects which do not deliver bundles (for example agregator projects) it
is acceptable to use a short descriptive artifactID.
1. The group ID will overlap with the artifactId and will normally be of the
form org.apache.aries.\{subproject\}