Comments inside.. 2011/1/11 Eric Charles <[email protected]>: > (quick answer) > > - Yes, 43 is much... The idea behind was the osgi track (can't find the > articles from pax project where they argue to have real small modules, even > micro modules, rather than larger one). > - Your proposal to have persistence-* is good because it will not oblige to > load unneeded dependencies (if you need jpa, you don't have jcr,..) > - Btw, must we keep jdbc. I would simply deprecate it in favor of jpa.
+1 > - I think some user will still use mixed persistence (ex: ldap for user and > maildir for mailbox), so I would prefer keeping all flexibility (this is why > we have no fk in jpa between user and mailbox). I think we would even be flexible with stefano's proposal. > - If we have to merge project, I would even simply move them out of server, > having a persistence project such as imap, mailbox,... -1 I think we will just end up with just another project wich we need to release before a server release can get cut.. > - No idea about queue-*. > > Tks, > > Eric > > > On 11/01/2011 16:05, Stefano Bagnara wrote: >> >> You know I finally had some time to review current trunk and I fear we >> have too many modules: we removed protocols, imap and mailets but >> still we have 43 modules. 43! >> Many modules counting less than 4 classes. >> >> Here is a choice of current modules and the number of classes they >> contains: >> >> - mail-file(3) >> - mail-jcr(1) >> - mail-jdbc(3) >> - user-jpa(4) >> - user-file(2) >> - user-jcr(2) >> - user-jdbc(4) >> - domainlist-jpa(2) >> - domainlist-xml(1) >> I only see benefits and no drawbacks in consolidating the 9 modules >> above to the following 4 modules: >> persistence-jpa(6) = user-jpa(4)+domainlist-jpa(2) >> persistence-file(6) = user-file(2)+mail-file(3)+domainlist-xml(1) >> persistence-jcr(3) = user-jcr(2)+mail-jcr(1) >> persistence-jdbc(7) = user-jdbc(4)+mail-jdbc(3) >> >> - mail-library(1) >> - domainlist-library(2) >> - user-library(9) >> We could consolidate them into a persistence-library module (from 3 to >> 1 module). >> persistence-library(12) = >> mail-library(1)+domainlist-library(2)+user-library(9) >> >> - queue-library(2) >> - queue-jms(5) >> We could merge queue-library to queue-jms (a library module makes >> sense when we do something useful.. if it is trivial stuff it can be >> duplicated or moved to the api layer). >> queue-jms(7) = queue-jms(5)+queue-library(2) >> >> The 3 steps above would reduce the number of modules of 8. >> >> The main advantages of using modules is being able to isolate >> dependencies, so I consolidated modules sharing the same dependencies. >> To understand what "module" is implemented by each persistence adaptor >> one can easily look at the packages inside the module. >> >> If people will one day contribute mail-jpa code or domainlist-jcr or >> domainlist-jdbc we don't have to add 3 new modules but simply really >> few new classes to their respective persistence functions. If we had >> the 3 missing implementations we could bring this "consolidation" also >> to the configuration side: while I see cases where mixed persistence >> is used, in my opinion most users will simply stick to a single >> persistence type for everthing. So it would be convenient to simply >> let the user choose the persistence method (file, jdbc, jcr, jpa) and >> then automatically choose the 3 right service implementations. >> >> Stefano >> Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
