Developer Guide

This guide is intened to be read by those who participate into the development of the LDAP API. Users of the API are expected to read the User guide.

Getting the source, Building the trunks

To get the source, build the trunks/shared and get along with Maven.

Versioning Scheme

The version number of LDAP API has the following form:

<major>.<minor>.<micro> \[-M<milestone number> or -RC<release candidate number>]

This scheme has three number components:

  • The major number increases when there are incompatible changes in the API.
  • The minor number increases when a new feature is introduced.
  • The micro number increases when a bug or a trivial change is made.

and an optional label that indicates the maturity of a release:

  • M (Milestone) means the feature set can change at any time in the next milestone releases. The last milestone release becomes the first release candidate after a vote.
  • RC (Release Candidate) means the feature set is frozen and the next RC releases will focus on fixing problems unless there is a serious flaw in design. The last release candidate becomes the first GA release after a vote.
  • No label implies GA (General Availability), which means the release is stable enough and therefore ready for production environment.
A stable version is a version with a frozen set of features, and a frozen API. We don't release a version if all the integration tests are not passing, so any release should be considered stable enogh to be used.
Although we may add new features between two milestones, and the data structure may change, which may imply that the data have to be extracted and reimported in order for the server to be operational.
The configuration might also evolve between two versions.

Coding standards

The applicable coding standards for LDAP API 1.0 are described in Coding Standards

There are some more rules, as we are using Java 6 now :

  • Use generics as much as you can. Generic are a good way to avoid casting, and it enforce the usage of the correct type.
  • If you can avoid Iterators, do so. There is this cool construction with a for( Type t: ) : use it !
  • Use assert. It's usefull, especially instead of a bunch of if () then throw Exception* when controlling incoming parameters
  • Use the new Enum type !

Releasing the LDAP API

Here is a guide on how to cut a new release. This is a long process, expect it to last a couple of hours !

First, you need to have a recent version of Maven (we are using 3.0.4) and a recent version of the JDK (1.7 is ok, it should also build with 1.6).

Maven Settings

You'll need a settings section for the Nexus and servers with a password or a path to the SSH key used. Here's what my settings.xml file in ~/.m2 looks like:


    <!-- To publish a snapshot of some part of Maven -->

    <!-- To publish a website using Maven -->

    <!-- To stage a release of some part of Maven -->

    <!-- To stage a website of some part of Maven -->
      <id>stagingSite</id> <!-- must match hard-coded repository identifier in site:stage-deploy -->



      <!-- Configuration for artifacts signature -->


Just replace your username, passwords and paths. Note that the username and password is your Apache LDAP account.

You'll need to provide the passphrase in the settings.xml to access the gpg secret key installed on your host. This is due to a bug with the passphrase prompt in the maven-gpg-plugin. So unfortunately we must provide the passphrase in the settings.xml file in clear text. This should change in the future when this bug is fixed. Note that this passphrase is put into the release profile which we activate to properly sign and release the artifacts and poms via the release plugin.


All subprojects are configured to deploy signatures for the artifacts uploaded to the repository. The gpg plugin will check use the default gpg key for the user deploying the project with the release:perform directive of the release plugin. This will prompt you for the passphrase for the default key. If you do not have one setup the build will fail.

You can generate and upload a PGP key to a PGP keyserver using the following commands:

gpg --gen-key
gpg --fingerprint
gpg --keyserver --send-keys <your key's id from last command>
Make sure to have created the .pgpkey in your p.a.o/~ directory and to have added your public key to the KEYS file. See also

Release process

Since we are using Nexus for releases the release process is as follows (see also Publishing maven artifacts).

Test the Project

$ mvn release:prepare -DdryRun=true

Be aware that this phase will ask you about the next version, and most important, for the next SCM tag :

[INFO] Checking dependencies and plugins for snapshots ...
What is the release version for "Apache Directory LDAP API"? ( 1.0.0-M16: : 
What is the release version for "Apache Directory LDAP API I18n"? ( 1.0.0-M16: : 
What is the release version for "Apache Directory LDAP API Utilities"? ( 1.0.0-M16: : 
What is SCM release tag or label for "Apache Directory LDAP API"? ( 1.0.0-M16: :

Deploy a Snapshot

$ mvn deploy

This is useful to verify your settings in ~/.m2/settings.xml (Nexus password and GPG key)

Prepare the Release

$ mvn release:clean
$ mvn release:prepare

This creates a tag here

Stage the Release

$ mvn release:perform

This deploys the release to a staging repository.

Go to the nexus server and close the staging repository.

Build the Site

$ cd target/checkout
$ mvn site

This creates the site.

Sign the packages

Now, you have to sign the binary packages which are in target/checkout/distribution/target.

Use your PGP key ID (the pub key, 4096R/[XXXXXXX] where [XXXXXXX] is the key ID)

You can get the keys by typing :

gpg --list-keys

The produced packages already have .asc signature that you will need to remove :

$ cd target/checkout/distribution/target
$ rm *.asc
$ ~/
PGP Key ID: 
<You public key>
PGP Key Password: 
<Your password>
-n Signing: ./apache-ldap-api-1.0.0-M25-bin.tar.gz ... 
  - Generated './apache-ldap-api-1.0.0-M25-bin.tar.gz.md5'
  - Generated './apache-ldap-api-1.0.0-M25-bin.tar.gz.sha1'
  - Generated './apache-ldap-api-1.0.0-M25-bin.tar.gz.asc'
-n Signing: ./ ... 
  - Generated './'
  - Generated './'
  - Generated './'

You are done with the signature.

For the record, here is the script shell you can use to sign the packages. Name it, and put it into your home directory (on a unix based computer) :


echo "PGP Key ID: "

echo "PGP Key Password: "
stty -echo
stty echo
echo ""

for FILE in $(find . -maxdepth 1 -not '(' -name "" -or -name ".*" -or -name "*.md5" -or -name "*.sha1" -or -name "*.asc" ')' -and -type f) ; do
    if [ -f "$FILE.asc" ]; then
        echo "Skipping: $FILE"

    echo -n "Signing: $FILE ... "

    # MD5
    if [ ! -f "$FILE.md5" ];
        openssl md5 < "$FILE" | cut "-d " -f2 > "$FILE.md5"
        echo "  - Generated '$FILE.md5'"
        echo "  - Skipped '$FILE.md5' (file already existing)"

    # SHA1
    if [ ! -f "$FILE.sha1" ];
        gpg -v --default-key "$DEFAULT_KEY" --print-md SHA1 "$FILE" > "$FILE".sha1
        echo "  - Generated '$FILE.sha1'"
        echo "  - Skipped '$FILE.sha1' (file already existing)"

    # ASC
    if [ ! -f "$FILE.asc" ];
        echo "$PASSWORD" | gpg --default-key "$DEFAULT_KEY" --detach-sign --armor --no-tty --yes --passphrase-fd 0 "$FILE"
        echo "  - Generated '$FILE.asc'"
        echo "  - Skipped '$FILE.asc' (file already existing)"

Publish Source and Binary Distribution Packages

First of all, create a new directory on to store the pacckages :

$ ssh
$ mkdir public_html/ldap-api-<version>
$ exit

Then copy the packages :

$ cd distributions/target
$ scp apache-ldap-api-<version>-*<version>/

Update your index.html file on to make the packages visible. Here is an example of possible content :

<h2>Last Directory LDAP API 1.0.0-M16 tarballs</h2>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-bin.tar.gz">apache-ldap-api-1.0.0-M16-bin.tar.gz</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-bin.tar.gz.asc">apache-ldap-api-1.0.0-M16-bin.tar.gz.asc</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-bin.tar.gz.md5">apache-ldap-api-1.0.0-M16-bin.tar.gz.md5</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-bin.tar.gz.sha1">apache-ldap-api-1.0.0-M16-bin.tar.gz.sha1</a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-src.tar.gz">apache-ldap-api-1.0.0-M16-src.tar.gz</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-src.tar.gz.asc">apache-ldap-api-1.0.0-M16-src.tar.gz.asc</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-src.tar.gz.md5">apache-ldap-api-1.0.0-M16-src.tar.gz.md5</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16-src.tar.gz.sha1">apache-ldap-api-1.0.0-M16-src.tar.gz.sha1</a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/"></a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16.pom">apache-ldap-api-1.0.0-M16.pom</a><br/>
    <a href="ldap-api-1.0.0-M16/apache-ldap-api-1.0.0-M16.pom.asc">apache-ldap-api-1.0.0-M16.pom.asc</a><br/>

Test the New Version in ApacheDS and Studio

In apacheds/pom.xml change the property, build ApacheDS, go into apacheds/service, and run ./ to start the server.

In studio/pom.xml change the and properties, build Studio, and start Studio in applications/applications_/target/ApacheDirectoryStudio-/. Connect to the started ApacheDS.

Stage the release

Go to and close the staging repository.


Start a 72h vote at the dev mailing list.


If the vote succeeds LDAP API project can be released.

Go to and release the staging repository so all artifacts are published to Maven central.

Move the distribution packages (sources and binaries) to the dist SVN repository:$(version)

The best solution would be to checkout the directory in, to copy the packages in the right place, and to check in the changes (we assume you have a dist-all/api directory in your home directory. if not, create it) :

$ ssh
# cd dist-all/api
# svn co dist
# cd dist
# mkdir <version>
# cp ~/public_html/ldap-api-<version>/* <version>
# svn add <version>
# svn ci <version>
# exit

The packages should now be available on

Deploy the Javadocs and XRef

We now can deploy the generated Javadoc and cross-reference pages. They are generated in the following directory :


We will copy two directories :


Staging or Production?

Those files will be stored on the production server only !!! And some extra caution ust be taken not to delete them when we will publish the staging site too...

First of all, you must checkout the two CMS store for the site : staging and production.

$ cd ~/apacheds
$ svn co staging
$ svn co production

Now, you will first add the directory for the newly generated version :

$ cd ~/apacheds/production/content/api/gen-docs
$ mkdir <version>
$ svn add <version>

Then copy the generated docs :

$ cp -r ~/apacheds/trunks/shared/target/checkout/target/site/apidocs ~/apacheds/production/content/api/gen-docs/<version>
$ cp -r ~/apacheds/trunks/shared/target/checkout/target/site/xref ~/apacheds/production/content/api/gen-docs/<version>

You have to check in those directories :

$ svn add <version>/*
$ svn ci <version> -m "Injected <version> javadocs"

Now, you have to update the staging site extpaths.txt

This file list the file on the production site that will not be overriden by the publication of the staging site. It has to be updated

$ cd ~/apacheds/staging/content/
$ vi extpaths.txt

Add the following line :


then save and check in the file extpaths.txt

We also have to update the .htaccess file :

$ cd ~/apacheds/staging/content/api/gen-docs
$ vi .htaccess

And update the two last lines to refer to the version you've just released :

RewriteRule ^latest$ <version>/
RewriteRule ^latest/(.*)$ <version>/$1

Save and commit the file.

Update the web site

You can now update the site, add a news on the front page, and publish the site.

There are a few places to modify :

  • /lib/ : update the $version_api variable with the new version.
  • /content/index.mdtext : same here, update the section, which contains the version.
  • /content/api/news.mdtext : add the news on top of this page
  • /content/api/download-old-versions.mdtext : add a new line on top of the array, which refers to the latest version before the new one

Commit the changes, and publish the web site, you are done !

Inform the world !

After 24h, you can now inform the world about the release.

Send a mail to the users and dev mailing list, and one to the

You are done !