modules/ROOT/pages/development/guidelines.adoc

= Coding guidelines

== 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

== Maven best practice in Aries development

=== 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:

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

=== Good practice in the pom

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

=== Group and Artifact names

. 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.
. The group ID will overlap with the artifactId and will normally be of the form org.apache.aries.\{subproject}