james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject [PROPOSAL] add one more "layer" to the server.trunk ant build
Date Tue, 05 Aug 2008 11:23:10 GMT
The issue raised in 3 different current threads, so maybe it is better 
to talk about it in a new thread.

While creating more modules there is the case where we use many utility 
classes in our codebase.

The current ant build is by purpose organized in 4 layers:
- deployments
- functions
- libraries
- apis

Each layers module can only depends on modules in the underlying layers.

What layer a module belongs to is automatically recognized by looking at 
the module suffix.

Currently our utilities are "hosted" in library modules, and this make 
them useless to other library modules (utilities cannot be shared 
between libraries).

There is a long term plan of removing the utilities at all or to move 
them to external libraries (hosted by JAMES or as part of already 
existing Apache "Commons" libraries). My opinion is that similar plans 
tend to move attention/efforts to the wrong goal.


I propose that we introduce a new kind (or two) of module at the same 
level of the api module, so it would be:
- deployments
- functions
- libraries
- apis | commons | utils

The new modules MUST have no dependencies on other modules as for APIs 
but they are not API so having new types would help our refactoring in 
the short term.

I think this would also be useful to move some library code "down" to a 
common/util module because this automatically make it clear that the 
code have no dependencies on other servers libraries.

I see the need for:

deliverynotification code being discussed in "[server.trunk] introducing 

we then have some stream handling class, a security/digest class, maybe 
some encoding/decoding class having no dependencies and being used by 
unrelated code. My proposal is to put everything else in a single module 
as a first step, and evaluate next steps once we see what ended up 
inside the module.

Maybe "deliverynotification-util" and "common-util" are good names for 
the "-util" case, or "deliverynotification-common" and "util-common" are 
an alternative in the "-common" case.

ATM I would go with the -util suffix.

An alternative would be to use "-library" for the utilities (code with 
no dependencies) and "-impl" for current libraries (they often are 
implementations of stuff we have in -api modules). I don't have a strong 
opinion on the best solution, I just have a strong feeling that we need 
a fast/"easy to adopt" solution to accomplish a better modularization.



To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message