Hi, >From the peanuts gallery I'll just observe that since we started Sling >seven years ago we are constantly moving towards smaller and more >specific modules (OSGi bundles in that case), even though we already >have many of them.
Having many many Maven projects makes it very hard to understand and follow the code in my view. It's not spagetti code but ravioli code (in the sense of an anti-pattern). See also http://stackoverflow.com/questions/2052017/ravioli-code-why-an-anti-pattern I very much prefer if things that belong together stay together, and are not taken appart into *-api, *-common, *-impl projects. Because taking things apart makes maintenance very hard. Testing is always a challenge, and testing many possible combinations of bundles in different version is just not possible. Sure, *most* bugs are in one module, but some bugs only show up with certain combinations. For example OAK-3169, which only showed up with the DocumentNodeStore, in combination with an IBM JVM version 1.6 (not with a Sun JVM, and not with an IBM JVM version 1.7). >Grady Booch's rule that "a class should do one thing and one thing >well" applies very well to modules/bundles IMO, being specific makes >many things easier and many modules become trivial and change rarely >which helps focus efforts in the right places. Grady Booch talks about classes not about Maven projects. My experience with having many Maven projects is that it is just additional overhead, without real benefit. For Jackrabbit Oak, same as for Apache Lucene (for example), I don't see how splitting into modules would help. It mainly brings in complications. Regards, Thomas
