On 06/08/15 13:36, "Davide Giannella" <[email protected]> wrote:
>Grouping two emails together > >On 06/08/2015 12:04, Michael Dürig wrote: >> I neither like Sling's "constantly moving towards smaller and more >> specific modules" as too me this seems to be mostly driven by OSGi as >> a technology and not by modularisation as a way to balance complexity, >> maintainability and reusability. This might be opinionated and >> ignorant due to my overall lack of Sling knowledge though. So let's >> not get sidetracked with a Sling fight here ;-) >> >> >> > Having many many Maven projects makes >> >> See my proposal. This is not about having many Maven projects but >> reasonable module boundaries. The definition of which is low cohesion >> between modules and hight cohesion within them. >> >> To quote from the Wikipedia article linked from the Stackoverflow post >> you cited (emphasis mine): "While generally desirable from a coupling >> and cohesion perspective, *overzealous separation* and encapsulation >> of code can bloat call stacks and make navigation through the code for >> maintenance purposes more difficult." >> >> "overzealous separation" being key here! >... > >> I'd prefer to slowly move towards a more modularised Oak. One such an >approach could be: >> >> - Move NodeStore implementations into their own modules. >> >> - Leverage OSGi sub-systems to hide Oak's private parts (i.e. all that >component we export just for ourselves). >> >> - Fine tune over time, evaluate what worked and what not and follow up >from there. > >Once again I totally share Michael's point. It seems you're reading my >mind :) > >Davide I also like the idea of slowly moving towards modularisation. In the beginning we could start with “only” subsystems in OSGi and move the stable API parts out into single bundles over time. That would allow for an initial set of modules that can be re-viewed/ refactored a few releases later without invalidating the exposed contract. >
