I think move stuff out of server should not get done.. Also I think we would make better just call it "jpa", "jcr" ... No need to prefix it with persistence.
Bye, Norman 2011/1/11 Eric Charles <[email protected]>: > Commenting while thinking: > - moving persistence-* out-of- server sounded good to me, but we will face > release issue (a release is some work), so it should be forgotten. > - 'persistence' naming is well representative, but we also have the > 'mailbox' which is the mail persistence: I expect confusions for > new-comers... > > Tks, > > Eric > > > On 11/01/2011 18:05, Eric Charles wrote: >> >> (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. >> - 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). >> - If we have to merge project, I would even simply move them out of >> server, having a persistence project such as imap, mailbox,... >> - 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 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
