Hi, comments inside again :)
2011/1/11 Stefano Bagnara <[email protected]>: > 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. Statistics are fun :) > > 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.. > I agree with you maybe we should "step-back" and merge some of them again.. > 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) To be honest I think activemq packaging suxx. They should at least provide some "client-only" jar for those who don't want to run an embedded broker. I remeber there is a ticket for that which lack some love.. > - cassandra counts 429 classes in 8 modules (54 avg) > Same as above > 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. When you say module what exactly you count ? It sound like you not count the "<module></module> in the pom.xml.. > >> - 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). true.. > >> - 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.... +1, I agree > >> [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). Well the maildir stuff is a bit of some special "glue" code.. It's only needed because we want to use some special parent dir depending if we use virtualhosting or not. > > 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. I see your point, but I'm not 100% convided yet ;) > > Stefano > > --------------------------------------------------------------------- Bye, Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
