On Feb 2, 2008 6:39 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > 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.
<snip> > Our JDBC based repositories also depends on avalon because they supports > both db and dbfile "protocols". yes - IMHO they're all avalon backends > 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. +1 > 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.*). the security stuff would probably be better as an independent sub-project > 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. +1 > org.apache.james.domain.* > - backend implementation: contains XML and JDBC version (and common > abstract code). no other module depends on this. i > 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. a mailbox API makes a lot of sense: given the number of modules, we'll probably end up moving some code into separate sub-projects. mailbox (including IMAP and so on) is a good candidate. > 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) +1 > org.apache.james.util.Lock > - belongs to the repository logic +1 > 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. the sieve mailets are a bit of an issue but i agree that it belongs with them > 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. i'd like to separate the DNS code into domain > org.apache.james.util.JDBCBayesianAnalyzer > org.apache.james.util.BayesianAnalyzer > - they deserve their own package. And maybe they belong to the backend > stuff. maybe the bayesian stuff would be better in a separate sub-project > org.apache.james.util.urirbl.* > - this is smtpserver-function stuff. maybe we can move this package > there, for the moment. +1 > 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? +1 > 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). i'd like to split out the DNS into domain modules > 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. +1 > 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. +1 quite possibly commons may take any missing functions > org.apache.james.util.mailet.* > - this code is only used by some of our mailets. move into standard mailets sub-projects > 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?) something like that > org.apache.james.services.* > - ehm.. time is running out and this package is tricky.. so let's delay > it for a while ;-) i would like to push these into API modules grouped by semantic function. eg MailetLoader -> spool [extension] MailProcessor -> spool [extension] BayesianAnalyzerManagementService -> bayesian mailet [management] DomainListManagementService -> domain [management] FileSystem ??? JamesConnectionManager ??? management MailRepository -> mail [extension though ATM service] MailServer -> mail [service] ManageableDomainList -> domain [management] MatcherLoader -> spool [extension] ProcessorManagementService -> spool [management] SpoolManagementService -> spool [management] SpoolRepository -> spool[extension] note that spool and mail repositories are going cause difficulties with coupling: may need some refactoring i would like to see all APIs repackaged into sub-packages of org.apache.james.api grouped first by functional area and then into service, extension and management APIs - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
