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