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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
