Robert Burrell Donkin ha scritto:
i now wonder whether it might be better to aggregate backend classes
according to the technologies they use. so (for example) any backend
code that uses torque would be in a torque-backend module, any code
that uses avalon to store data in a avalon-backend module and so on.
any backend implementations that just use java would be moved into a
base-backend module.
This could not be so easy.
Our torque function also depends on avalon services.
Our JDBC based repositories also depends on avalon because they supports
both db and dbfile "protocols".
BTW I think we should at least (as a first step) separate backend code
from other core library classes. Core-library contains too much
unrelated code ATM.
I run a few grep to see what modules/code import each class/package in
core-library and here are some considerations:
org.apache.james.security.*
- they are only used by spoolmanager-function, and only by smime mailets
(org.apache.james.transport.mailets.smime.*).
org.apache.james.management.*
- this package is imported by remotemanager-function and by core-library
itself (org.apache.james.services). There is a cyclic dependency issue
between org.apache.james.management and org.apache.james.service that
should be resolved as a priority.
org.apache.james.domain.*
- backend implementation: contains XML and JDBC version (and common
abstract code). no other module depends on this.
org.apache.james.mailboxmanager.*
- imap-mailbox-processor-function, imapserver-function,
torque-mailboxmanager-function depends on this.
- sieve mailets in "spoolmanager-function" depends on this (I would like
to see this dependency removed)
- phoenix-deployment depends on this because of
PhoenixImapProcessorFactory and TorqueMailboxManagerFactory
I think the whole mailboxmanager package could be moved to a different
library module as no other core-library class depends on it, but I'm not
sure the current api-library-function-deployment layers let us to do
this right now, unless we move some class down to an api module.
org.apache.james.core.*
- this is a problematic package. This contains some core James object
like MailImpl/MimeMessageWrapper/MailHeaders but also contains common
components for current protocol functions
(AbstractJamesHandler/AbstractJamesService).
org.apache.james.util.watchdog.*
org.apache.james.util.connection.*
- they are related to AbstractJamesHandler/AbstractJamesService.
org.apache.james.util.junkscore.*
- is only used by smtpserver-function (we might move this in the
function itself)
org.apache.james.util.Lock
- belongs to the repository logic
org.apache.james.util.mail.mdn.*
- only used by sieve mailets. This is almost standalone utility code,
maybe we should move this where we move sieve mailets, or give them a
custom module (this depends on how we'll reorganize mailets). It imports
org.apache.james.util.mail.MimeMultipartReport and the
org.apache.james.util.mail.handlers.* classes.
org.apache.james.util.mail.dsn.DSNStatus
- utility class used by smtpserver and by the DSNBounce mailet. To make
DSNBounce a non-James-specific mailet we have to move this somewhere
else, but where??
org.apache.james.util.mail.MimeMultipartReport
org.apache.james.util.mail.handlers.*
- they are used by DNSBounce and by the mdn code. Something along the
line of the DSNStatus destiny.
org.apache.james.util.JDBCBayesianAnalyzer
org.apache.james.util.BayesianAnalyzer
- they deserve their own package. And maybe they belong to the backend
stuff.
org.apache.james.util.urirbl.*
- this is smtpserver-function stuff. maybe we can move this package
there, for the moment.
org.apache.james.util.POP3BeforeSMTPHelper
- this is "weird" because it links pop3function to the smtpfunction
(smtpserver.core.POP3BeforeSMTPHandler, pop3server.PassCmdHandler). It
is an smtp specific feature)
org.apache.james.util.DotStuffingInputStream
org.apache.james.util.SchedulerNotifyInputStream
org.apache.james.util.CharTerminatedInputStream
org.apache.james.util.ExtraDotOutputStream
org.apache.james.util.InternetPrintWriter
org.apache.james.util.TimeConverter
org.apache.james.util.Base64
org.apache.james.util.CRLFTerminatedReader
org.apache.james.util.SqlResources
- utility classes. maybe we should remove oro dependency from
timeconverter. Some of them are specific to our
AbstractJamesHandler/AbstractJamesService stuff)
org.apache.james.util.MatcherInverter
- belongs to the util.mailet package. should we move it there?
org.apache.james.util.NetMatcher
- used by many mailets and by some smtpserver code. it depends on the
DNSServer, and I wonder if it should better depends on a modified Mailet
API (including the getByName method).
org.apache.james.util.dbcp.JdbcDataSource
- this is avalon/excalibur function code. it implements the
org.apache.avalon.excalibur.datasource.DataSourceComponent interface and
is only used via that service. belongs to the backend.
org.apache.james.util.io.*
- maybe we should remove this in favor of commons-io library. This is
pure java, no deps, utility code for IO. I guess this was once avalon
code, that has been integrated in james because of avalon death but also
found his way in jakarta commons.
org.apache.james.util.mailet.*
- this code is only used by some of our mailets.
org.apache.james.context.*
- this is a function code. It is the Avalon/Phoenix implementation of
our FileSystem service. Should be moved away from this module (phoenix
deployment?)
org.apache.james.services.*
- ehm.. time is running out and this package is tricky.. so let's delay
it for a while ;-)
HTH,
Stefano
PS: maybe all of this message is OT, and the subject should be "what do
we have in core-library?" ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
