directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Burch <>
Subject Re: [VOTE] Apache LDAP API 1.0.0 release
Date Sun, 04 Jun 2017 07:58:40 GMT
On 04/06/17 16:50, Emmanuel Lécharny wrote:
> Le 03/06/2017 à 09:26, Brian Burch a écrit :
>> On 03/06/17 12:39, Emmanuel Lécharny wrote:
>>> Le 03/06/2017 à 04:31, Brian Burch a écrit :
>>>> On 03/06/17 12:02, Emmanuel Lécharny wrote:
>>>> So... do you propose to update the surefire version to 2.19.1 in the
>>>> API pom.xml?
>>> It's already using this version :-)
>> Thanks for explaining. I can see the "trunks" pom.xml calling the
>> "project" module. I found "project has a tag of 40, which holds a
>> pom.xml with the preferred version of the surefire plugin. That
>> pom.xml is at revision 1797473, which corresponds to the latest
>> revision of the API 1.0.0.
> Let me explain a bit the way we use maven...
> Directory is quite a big project. Actually, it's more than a single
> project :
> - ApacheDS (the LDAP server)
> - Studio
> - Mavibot (the new database)
> - JDBM (the current database)
> and a few more things, slightly disconnected (kerby - the standalone
> kerberos server -, eSCIMo - a SCIM implementation -, Fortress -a RBAC
> implementation -...)
> All in all, we are talking of more or less 1 million single line of code
> (ie, just counting the code, not the blank lines or comments).
> At this point, we needed some organization that supports the whole stuff.
> The main projects (ie, ldap API aka shared, ApacheDS, Mavibot and
> Studio) are pretty much standalone. You can pull everything as a whole
> by checking out This
> is a convenient way to get everything, it uses svn externals (ie, links
> to sub projects that subversion will pull automatically).
> Usually, you just need a couple of projects, like API and ApacheDS. If
> you are just interested in those two, it's enough to check out those two :
> svn co api
> svn co apacheds
> You'll get two standalone projects in two different directories that
> will build without neeing anything else.
> For convenience, we have gathered all teh maven lugin dependencies into
> a common project, called 'project', so that we don't need to declare
> those maven dependencies in each separate project. When we cut a
> release, we try to first update this common 'project' project with the
> latest maven dependency versions. You usually don't have to care abut
> it, it's really an facility offered to the projects.
> Now, if you consider the API, or ApacheDS, each project is around 200
> Ksloc each, so it's one fifth the size of the global project. It's still
> big, and we have a lot of maven modules. For instance :
> api                The root
>    all              Builds a package containing everything but tests
>    asn1             The ASN.1 part
>      api            The ASN.1 API
>      ber            The ASN.1BER encoding rules
>    distribution     The module that creates the binary packages
>    dsml             DSML implementation
>      engine         The DSML engine
>      parser         The DSML parser
>    i18n             Internationalisation (ie, messages, etc)
>    integ            Integration tests
>    integ-osgi       Osgi tests
>    integ-osgi2      Osgi tests, part 2
>    ldap             The LDAP API root
>      client         The Client part
>        all          Create a package for the LDAP client (we don't
> package the server parts)
>        api          The client API
>      codec          The LDAP encoding/decoding part
>        core         The codec core
>        standalone   The non-OSGi codec
>      extras         LDAP Extensions
>        aci          Access Control Items
>        codec        Extended codec for controls and extended operations
>        codec-api    The extended codec API
>        sp           Stored procedure
>        trigger      Triggers
>        util         Self explicit :-)
>      model          The LDAP model (Entry, Attrinutes, name, etc)
>      net            The network layer
>        mina         MINA based implementation
>      schema         The LDAP schema utilities
>        converter    The schema converter (OpenLDAP -> ApacheDS)
>        data         The schema itself
>      util           Generic utilities
> We have another long hierarchy for Apacheds with more or less 50 modules.
> One generic rule : *don't touch the pom.xml !* :-) It's as it is for
> around 10 years now, it works pretty well, so better trusting it
> blindly. Usually, you just have to import the top-level pom into your
> prefered IDE (Eclipse, Intellij, Netbeans), it will do the trick. I use
> Eclipse because Studio is an eclipse based LDAP UI, but any other IDE
> would do the trick, except for Studio.
> Hope it helps.

Yes it does. Thank you very much for taking the time to explain - I hope 
your effort was not just for me!!

I'll file this email away and add it to my "to do" list. When I 
(eventually) get round to my overdue pending wiki updates, I will check 
to see whether any of your explanation can be added (assuming, of 
course, that it isn't there already!).


View raw message