Hi Stefano, the idea was to make it easy to use and deploy them in an osgi container without the need to not needed dependencies.. You know in OSGI you will see a dependency hell really fast ;)
For details see inline.. 2011/1/11 Stefano Bagnara <[email protected]>: > 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! Wow I wasn'T aware that we have such many ;) > 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) I can see your point and I think at the end it would work even in OSGI. You would just need to be sure that the "*-api" is in place. So I think the *-api modules should stay.. > > - 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) > Need to review the impact. Not sure atm > - 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) > I see your point. So +1... > 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]
