james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James D Carroll <jamesdcarr...@gmail.com>
Subject Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Date Sun, 10 Aug 2008 14:10:00 GMT
There's a company called Lattix (www.lattix.com) that makes a dependency
discovery tool that may help to tease out what dependencies are in the
code.  They offer a free license to open source projects.  Perhaps this
tool would be of assistance. I've always wanted to give it a try myself,
but if you guys find it useful, I'd love to see the results.

James

On Tue, 2008-08-05 at 13:23 +0200, Stefano Bagnara wrote:
> 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.
> 
> --------
> PROPOSAL
> --------
> 
> 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 
> mail-library"
> 
> 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.
> 
> Opinions?
> 
> Stefano
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
> 


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


Mime
View raw message