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).
Yes, depending on how you read "micro". I'd say micro is 10-20 classes, not 1-2 classes :-) Othewise OSGI should be better changed to load single classes as modules because it doesn't make sense to use jar as container of a single class :-) I agree that we should support OSGi but I think that what I'm proposing doesn't prevent osgi support: if instead there is some osgi blocker I'd like to know (i'm not an osgi guru, for sure). I like statistics: James 2.3 was 318 classes in a single module (and it included protocols and mailets) James-Trunk is 363 classes and 43 modules (an average of 8 classes per module), if you add protocols, mailets, imap, mailbox we reach more than 70 "private" jars in james distribution. So we moved from 318 to 8: a big jump.. maybe too big. I see both versions as bad extremes and that the best is in the middle: while a single monolitic product was a showstopper for new developers I think the same is true also when a developer wants to make a change to james and find that james is composed by 70 modules. Unless it is clear what we have in each module then we failed again with that goal.. Out of curiosity I had a look at other projects I happen to have checked out: - felix (they should know osgi well) includes 2485 classes in 126 modules (20 classes per module). interesting they have big core modules like org.osgi.foundation with 423 classes, org.osgi.compendium with 160 and org.osgi.core with 50. - activemq counts 1616 classes in 18 modules (89 classes average) - cassandra counts 429 classes in 8 modules (54 avg) Reducing the number of modules from 43 to 35 brings our average to 10 classes per module and it's clear we are still far lower than the average "new" java project. > - 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. If we don't need jdbc anymore we can't drop it, but this is "another issue" for another thread (first we have to provide a mail-jpa implementation I guess, unless we drop mail-* too). > - 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). Yes, consolidating the modules doesn't prevent mixed configurations. When you import an osgi bundle you are not forced to use all of the classes... As I wrote I think "most" users will use a single persistence and that should be the easy way: "fewer" users will use more advanced configurations and we should support them too. I guess no flexibility is compromised by consolidating modules like a proposed, but maybe I missed something.... > [from another mail] > - 'persistence' naming is well representative, but we also have the 'mailbox' > which is the mail persistence: I expect confusions for new-comers... I agree. FWIW i find already "confusing" to have mail-jcr in server-james and jcr in the mailbox product so I think we're only "moving" entropy around and not increasing entropy :-) On the other side maybe the current "mailbox-adapter" have something generic and something specific to the mailbox implementation used: I see we have maildir specific code there, not sure why we don't have the same specific code for jpa and jcr too. If we move to "persistence-$type" modules then we could add a "mailbox" package to each one for the specific wrapping stuff: persistence-file/mailbox would use mailbox-maildir, persistence-jcr/mailbox would contain mailbox-jcr specific adapters and so on.. (maybe I'm just saying stupid things.. I don't know mailbox enough.. just had a look at the mailbox-adapter module in server-trunk). This has minor drawbacks because importing "persistence-file" would bring also mailbox-maildir dependency but for a newbie developer (and for me too, not sure this qualify me as newbie too ) this would probably make easier to find stuff. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
