Stefano Bagnara ha scritto:
Hi all,
After I moved tests in the right places (excluding IMAP), I'd like to
sort out a better structure for our modules.
IMHO we have some modules that is not appropriate (domain-api, as an
example, contains unrelated interfaces, does not need to exist) and we
have the core-module that should be splitted into multiple modules.
The first thing I'd like to do is to create a "server-library" (or maybe
a listener-library / daemon-library) including code that is used by
services listening (pop3server, smtpserver, imapserver, nntpserver,
remotemanager).
While a wait an answer I'm working on this new module and I have questions.
1) any preference about the name? (it will include common code for
cornerstone/excalibur based tcp listening services)
2) InternetPrintWriter is used both by code that will belong to the new
module and by code used by other classes in core-library: I see we
already have another copy in imap-codec-library. Should I make another
copy or maybe it's better to have an "util-api" module (the name is
weird, but this is the "workaround" for introducing an utility module in
the current ant build)? I don't like code duplication so I would prefer
to have the "api name" workaround or to introduce multiple dependencies
levels in our build (maven does not have this limit, so ant build should
be updated someway)...
3) I identified this classes as candidates to be part of this new module:
util.connection.*
services.JamesConnectionManager
core.AbstractJamesService
core.AbstractJamesHandler
util.watchdog.*
core.CopyInputStream
core.SplitOutputStream
util.CRLFTerminatedReader
util.InternetPrintWriter (* see #2)
4) util.connection.* simply contains implementations for
services.JamesConnectionManager and they names are directly referred in
assembly.xml . IMHO they should be moved to a different package (they
are not utilities, they are implementations of a service!). Maybe they
should be moved and then we can create a compatibility-function module
(or maybe put them in the phoenix-deployment, so that we don't bring
this stuff to the spring deployment too) with classes in the old package
simply extending the one in the new package. Opinions?
5) Most classes I listed in #3 should be moved to better packages to not
overlap with already existing packages. Excluding
services.JamesConnectionManager and the util.connection package I
already discussed in #4 they are only used in james code and I think it
is unlikely they are widely used by JAMES users/developers, so I propose
to repackage them without creating a compatibility layer (we can create
it in case someone will complain). I would use:
"something.connman" instead of util.connection
"something.watchdog" instead of util.watchdog
"services.JamesConnectionManager" unchanged (ATM, for compatibility
reasons, and maybe moved to an API module later, but this is
cornerstone/excalibur specific)
"something" for every other class from core and util listed in #3.
Where "something" should be the same name we choose for the library name
(something-library, so, something could be "daemon", "listener",
"handler", or any other idea you may propose....). ATM I'm slightly for
something composite like "avalon-handler-library" and the "something"
package could be "handler.avalon"
I think the answer to this use case will allow me to proceed with other
simpler choices, too.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
