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)
- LDAP API
- 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 https://svn.apache.org/repos/asf/directory/trunks. 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 https://svn.apache.org/repos/asf/directory/shared/trunk api
svn co https://svn.apache.org/repos/asf/directory/apacheds/trunk 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!).
Brian
