james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject Re: [PROPOSAL] add one more "layer" to the server.trunk ant build
Date Tue, 05 Aug 2008 19:36:08 GMT
On Tue, Aug 5, 2008 at 12:23 PM, Stefano Bagnara <apache@bago.org> 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.
> --------
> --------
> 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.

i think we might want to move away from api-library-function but let's
take one step at a time

> Opinions?

as i read this proposal, it's not really adding any more layers, just
allowing more types of module in the lowest layer. basically, we add
one or two more naming conventions for modules that behave like APIs.
i'm reluctant to add more layers and would strongly prefer JAMES to be
coupled just by APIs but this proposal seems a reasonable stepping
stone to me.

- robert

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

View raw message