You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Francesco Mari <ma...@gmail.com> on 2015/08/06 10:51:13 UTC
Modularization
Hi,
In the past few days an offline conversation sparked about the
possibility of applying a certain degree of modularisation to
oak-core. I will try to summarise the main points of this
conversation.
Some team members expressed the will to extract some parts of oak-core
into their own modules. The reason for this refactoring are the
following:
- Bundles that do one and only one thing are more cohesive in their
implementation. Currently, oak-core does too many things and exposes a
low degree of cohesion.
- Bundles that are highly cohesive are easier to understand and, as a
consequence, to test and maintain. Some newcomers found difficult to
approach oak-core because they find it hard to understand.
- A better modularisation would allow semantic versioning for the
modularised components. A better versioning scheme would make clear if
a new version of a component is breaking client code or is an
acceptable replacement for a previous version.
- Providing and distributing a focused, small fix for a component is
easier if that component is contained in its own bundle, because it
prevents the release of oak-core in its entirety.
Some other team members didn't agree on the modularisation for the
following reasons:
- Oak is easy to understand because all the logic is contained in a
single project. Oak is a library and not a framework.
- Semantic versioning will not be of a big help, because the release
notes already give a good overview of the impact of every release.
- Too many modules are difficult to manage, burdening the development process.
I hope to have provided a comprehensive summary of the offline
conversation we had. If this is not the case, feel free to add or
clarify your point of view.
What is your take on modularisation?
Re: Modularization
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
In my view, "modularization" is not equal to "creating many Maven
projects".
>- Bundles that do one and only one thing are more cohesive in their
>implementation. Currently, oak-core does too many things and exposes a
>low degree of cohesion.
OK, this is your opinion, but I don't agree. I don't think that oak-core
does too many things. In fact, I think we would be better of if oak is
just one bundle.
>- Providing and distributing a focused, small fix for a component is
>easier if that component is contained in its own bundle, because it
>prevents the release of oak-core in its entirety.
That would require we completely change the way we work in Oak. We don't
release each module separately, and we don't test combinations of
versions. And I think that's OK, because doing that would lower the
quality and increase our work, without real benefit for anybody.
>- Semantic versioning will not be of a big help, because the release
>notes already give a good overview of the impact of every release.
I'm not sure how said that. I think semantic versioning is OK.
Regards,
Thomas
Re: Modularization
Posted by Philipp Suter <su...@adobe.com>.
On 06/08/15 13:36, "Davide Giannella" <da...@apache.org> 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.
>
Re: Modularization
Posted by Davide Giannella <da...@apache.org>.
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
Re: Modularization
Posted by Davide Giannella <da...@apache.org>.
On 06/08/2015 12:14, Bertrand Delacretaz wrote:
> On Thu, Aug 6, 2015 at 12:04 PM, Michael Dürig <md...@apache.org> wrote:
>> ...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....
> Which is exactly the reason for Sling moving to smaller modules in
> many places - create modules that Do One Thing And One Thing Well.
I always struggle navigating through the Sling codebase but indeed I
never really dedicated that much time. To me it feels a bit too many modules
> (and I'll end the Sling-based sidetracking now ;-)
>
;)
Davide
Re: Modularization
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Aug 6, 2015 at 12:04 PM, Michael Dürig <md...@apache.org> wrote:
> ...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....
Which is exactly the reason for Sling moving to smaller modules in
many places - create modules that Do One Thing And One Thing Well.
(and I'll end the Sling-based sidetracking now ;-)
-Bertrand
Re: Modularization
Posted by Michael Dürig <md...@apache.org>.
On 6.8.15 11:50 , Thomas Mueller wrote:
>> 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 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!
Michael
Re: Modularization
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Aug 6, 2015 at 12:25 PM, Thomas Mueller <mu...@adobe.com> wrote:
> Bertrand wrote:
>>...in Sling we are only testing very few combinations,
>>actually just one combination per release.
>
> Good to know! I still don't quite understand why you have many projects
> then... what is the driver to create smaller and smaller projects?...
To give two concrete examples:
https://issues.apache.org/jira/browse/SLING-3529 - the Sling launcher
contains code to detect if the current instance is a fresh one or an
upgraded one. There's currently no way to use just that startup mode
detection feature without using the full launcher, so we need to
extract it to make both things (launcher and startup mode detection)
reusable independently, when running Sling with other launchers like
Karaf for example.
https://issues.apache.org/jira/browse/SLING-4694 - Sling has a module
to detect media types based on filenames, and someone needed an
extension to also take the file contents into account. Creating that
extension in a separate module means that no changes were done to the
existing commons.mime module (which is a good indication of its
stability), and we don't bloat Sling with stuff that people might not
need - they can just decide to use the new bundle or not. Clean
separation between what's stable and what's in flux.
When I started with OSGi I was kind of afraid of having too many small
modules, as it felt harder to manage. We still ended up with more than
150 different modules released at
http://sling.apache.org/downloads.cgi, so having 100, 200 or 300 or
them does not matter much, and the benefits are obvious to in terms of
clearly differentiating what's in flux and what's stable.
I'm not saying Oak should have 300 modules...but maybe more than one ;-)
On Thu, Aug 6, 2015 at 1:37 PM, Davide Giannella <da...@apache.org> wrote:
> ...I always struggle navigating through the Sling codebase but indeed I
> never really dedicated that much time....
In a highly modular system you might need someone (or a debugger) to
help you find out where to look for something, but once you find that
the scope is much much smaller and it's much easier to make sure you
don't break things that you don't understand. IMO for a long-lived
project that's a huge benefit - and I always take
http://httpd.apache.org/ as a great example for that - very small
core, everything is a module.
-Bertrand
Re: Modularization
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Mon, Aug 10, 2015 at 8:50 AM, Philipp Suter <su...@adobe.com> wrote:
> ...I don’t think that it makes sense to have multiple separated maven projects for OAK...
FWIW, note that in Sling we do have a few independent Maven project trees:
-The main pom builds the core modules and their integration tests
-A separate contrib tree and main pom
-Another tree and main pom for tools (Maven plugins etc.)
I have found it useful to have a clear separation between the "sacred"
core modules and other less critical things. There's no excuse for
breaking the core build but we use a smaller trout to slap whoever
breaks the other ones.
-Bertrand
Re: Modularization
Posted by Philipp Suter <su...@adobe.com>.
I took some inspiration from Apache Aries for this hierarchical maven structure. It has very fine granular OSGi modules (not that we have to do that too) and still keeps everything in one hierarchical Maven project.
With a hierarchical maven project structure you can build/ test/ install either all of the projects in one go or just one of them.
I don’t think that it makes sense to have multiple separated maven projects for OAK. There will always be dependencies on each other and with a hierarchical structure these are kept in one place.
And you need some kind of “root” bundle that loads all dependencies within an OSGi container. In the OAK case most likely oak-jcr or oak-core.
On 07/08/15 11:31, "Thomas Mueller" <mu...@adobe.com> wrote:
>Hi,
>
>I have nothing against modularization, I'm just against "modularization =
>create many many Maven projects". I prefer modularization *within* one
>project. Why can't we do that instead?
>
>>Ideally you have a ³root² project, e.g.
>>
>>/oak
>> /security
>> /api
>> /implementationA
>> /implementationB
>> /core
>> /persistence
>> /..
>
>That looks like a Java *package* structure to me. The Wikipedia article
>you mentioned is not about Maven projects, but about modularity in general.
>
>Regards,
>Thomas
>
Re: Modularization
Posted by Francesco Mari <ma...@gmail.com>.
When I think about a module, in the context of splitting oak-core in
multiple modules, I think about an aggregation of code that can be
separately compiled and distributed. With the tooling currently in
place, this aggregation of code would be naturally represented by a
Maven artifact.
Thomas, you are clearly not in favour of adding more Maven artifacts
to Oak. How can we split oak-core in multiple modules without
resorting to Maven? How can we enforce the requirements of separate
compilation and individual distribution if we don't enclose a feature
in a Maven artifact?
2015-08-07 14:18 GMT+02:00 Tommaso Teofili <to...@gmail.com>:
> Hi all,
>
> I like the idea of a more modularized Oak.
> I agree with Michael's point of doing that gracefully, one step at a time,
> evaluate and iterate.
>
> My opinion is that "having one/many Maven projects" is not the central
> point of discussion; I don't personally think having e.g. 13 poms instead
> of 10 would be much of a problem anyway but I think we should mainly decide
> if we want to support different deployment scenarios, e.g. we ship modules
> oak-x, oak-y and oak-z for deployment-a and modules oak-x, oak-w and oak-z
> for deployment-b.
> I don't think in this case we would have to commit to supporting all the
> theoretically possible deployment scenarios / bundle combinations.
>
> I generally agree with Angela's point regarding layers as they were
> originally thought (and we ended up with NS & co.) but not clearly
> separated, however I have very few insights on that portion of oak-core's
> code.
>
> What I would like to have with a more modularized Oak is that if, for
> example, I want to fix something in the query engine I can do that and only
> get the bundle containing the core search stuff (query engine / indexing /
> searching), not the whole oak-core that in the meantime (always for
> example) requires an updated semantic version of oak-commons APIs.
>
> Regarding Apache Lucene: it is modularized in the sense that you can use it
> by just depending on lucene-core, but in most cases you'll most probably
> have to use some Analyzer implementations (lucene-analyzers-commons), query
> extensions (lucene-queries and lucene-queryparser), specific codecs
> (lucene-codecs) etc.
> I think that brings a good example where separation of modules (Ant ones,
> no comments please [1]) is performed by allowing usage of lucene-core alone
> but in most cases you'll end up using some of the companion modules.
>
> Regards,
> Tommaso
>
> [1] : https://issues.apache.org/jira/browse/LUCENE-3167
>
>
> 2015-08-07 11:31 GMT+02:00 Thomas Mueller <mu...@adobe.com>:
>
>> Hi,
>>
>> I have nothing against modularization, I'm just against "modularization =
>> create many many Maven projects". I prefer modularization *within* one
>> project. Why can't we do that instead?
>>
>> >Ideally you have a ³root² project, e.g.
>> >
>> >/oak
>> > /security
>> > /api
>> > /implementationA
>> > /implementationB
>> > /core
>> > /persistence
>> > /..
>>
>> That looks like a Java *package* structure to me. The Wikipedia article
>> you mentioned is not about Maven projects, but about modularity in general.
>>
>> Regards,
>> Thomas
>>
>>
Re: Modularization
Posted by Tommaso Teofili <to...@gmail.com>.
Hi all,
I like the idea of a more modularized Oak.
I agree with Michael's point of doing that gracefully, one step at a time,
evaluate and iterate.
My opinion is that "having one/many Maven projects" is not the central
point of discussion; I don't personally think having e.g. 13 poms instead
of 10 would be much of a problem anyway but I think we should mainly decide
if we want to support different deployment scenarios, e.g. we ship modules
oak-x, oak-y and oak-z for deployment-a and modules oak-x, oak-w and oak-z
for deployment-b.
I don't think in this case we would have to commit to supporting all the
theoretically possible deployment scenarios / bundle combinations.
I generally agree with Angela's point regarding layers as they were
originally thought (and we ended up with NS & co.) but not clearly
separated, however I have very few insights on that portion of oak-core's
code.
What I would like to have with a more modularized Oak is that if, for
example, I want to fix something in the query engine I can do that and only
get the bundle containing the core search stuff (query engine / indexing /
searching), not the whole oak-core that in the meantime (always for
example) requires an updated semantic version of oak-commons APIs.
Regarding Apache Lucene: it is modularized in the sense that you can use it
by just depending on lucene-core, but in most cases you'll most probably
have to use some Analyzer implementations (lucene-analyzers-commons), query
extensions (lucene-queries and lucene-queryparser), specific codecs
(lucene-codecs) etc.
I think that brings a good example where separation of modules (Ant ones,
no comments please [1]) is performed by allowing usage of lucene-core alone
but in most cases you'll end up using some of the companion modules.
Regards,
Tommaso
[1] : https://issues.apache.org/jira/browse/LUCENE-3167
2015-08-07 11:31 GMT+02:00 Thomas Mueller <mu...@adobe.com>:
> Hi,
>
> I have nothing against modularization, I'm just against "modularization =
> create many many Maven projects". I prefer modularization *within* one
> project. Why can't we do that instead?
>
> >Ideally you have a ³root² project, e.g.
> >
> >/oak
> > /security
> > /api
> > /implementationA
> > /implementationB
> > /core
> > /persistence
> > /..
>
> That looks like a Java *package* structure to me. The Wikipedia article
> you mentioned is not about Maven projects, but about modularity in general.
>
> Regards,
> Thomas
>
>
Re: Modularization
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
I have nothing against modularization, I'm just against "modularization =
create many many Maven projects". I prefer modularization *within* one
project. Why can't we do that instead?
>Ideally you have a ³root² project, e.g.
>
>/oak
> /security
> /api
> /implementationA
> /implementationB
> /core
> /persistence
> /..
That looks like a Java *package* structure to me. The Wikipedia article
you mentioned is not about Maven projects, but about modularity in general.
Regards,
Thomas
Re: Modularization
Posted by Philipp Suter <su...@adobe.com>.
Ideally you have a “root” project, e.g.
/oak
/security
/api
/implementationA
/implementationB
/core
/persistence
/..
Apache Aries has for example a pretty nicely structured hierarchical Maven set-up. You can still build all of it starting on top..
In the end smaller modules help theoretically with
- Risk assessment for deployments
- Test planing
- Rollouts
- Cleaner architecture
- Separation of concern
- Separation of necessary dependencies from unnecessary dependencies
- Customer specific implementation of API
https://en.wikipedia.org/wiki/Modular_programming#Key_aspects
On 06/08/15 15:28, "Thomas Mueller" <mu...@adobe.com> wrote:
>Hi,
>
>> we already have 2 modules for access control
>
>That's fine... What I meant is, we shouldn't try to move oak-core
>org.apache.jackrabbit.oak.security.** plus
>org.apache.jackrabbit.oak.spi.security.** to new Maven projects. Or should
>we?
>
>> jcr (top-bread)
>> core (meat with all the validation)
> > persistence
>
>
>I still don't see a reason why we should have "persistence" separate Maven
>project(s). What would it bring us? We anyway don't plan to combine
>"persistence 1.2" with "core 1.0", because we don't have testing in place.
>
>On the other side, I see many complications. We have datastore and
>blobstore, Mongo persistence from the RDB persistence are not completely
>independent (and they should not be), we have persisence wrappers
>(TimingDocumentStoreWrapper for example), caching (including persistent
>cache), discovery lite... If we want to create separate Maven projects for
>each of those (plus API projects, plus "commons" projects), we would
>easily have more Maven projects than we have Java packages right now.
>Sure, you could say we just create one "persistence" Maven project... but
>what for, really?
>
>Regards,
>Thomas
>
Re: Modularization
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
> we already have 2 modules for access control
That's fine... What I meant is, we shouldn't try to move oak-core
org.apache.jackrabbit.oak.security.** plus
org.apache.jackrabbit.oak.spi.security.** to new Maven projects. Or should
we?
> jcr (top-bread)
> core (meat with all the validation)
> persistence
I still don't see a reason why we should have "persistence" separate Maven
project(s). What would it bring us? We anyway don't plan to combine
"persistence 1.2" with "core 1.0", because we don't have testing in place.
On the other side, I see many complications. We have datastore and
blobstore, Mongo persistence from the RDB persistence are not completely
independent (and they should not be), we have persisence wrappers
(TimingDocumentStoreWrapper for example), caching (including persistent
cache), discovery lite... If we want to create separate Maven projects for
each of those (plus API projects, plus "commons" projects), we would
easily have more Maven projects than we have Java packages right now.
Sure, you could say we just create one "persistence" Maven project... but
what for, really?
Regards,
Thomas
Re: Modularization
Posted by Angela Schreiber <an...@adobe.com>.
hi thomas
hey... we already have 2 modules for access control. one
being just an optional implementation (module) that could be
plugged additionally once we have support for composite
authorization setup.
as far as i understood every single proposal and approach
that was made over the last couple of years to modularise Oak,
it always seemed perfectly reasonable to me. so far nobody was
asking for ripping apart all of the oak-core layer s.str
(the meat of the hamburger if you wish)... not mentioning that
this wouldn't be possible right now due to the plugins mess
we are having for the various JCR special areas.
what we have been discussing over and over again and what everyone
keeps proposing as a first step is: modularise based on the layers
that we originally designed and agreed upon.
having said that, i would like to remind you that we actually had
that separation of layers in the original setup where the
persistence layer was in a separate mk-api and mk-impl
module... it's only due to political whatsoever that we found
ourselves with abandoned mk-persistence modules and a new node
store persistence model that is awkwardly 'hidden' in oak-core.
so, my goal would be to restored the separation again now that
we officially got rid of the abandoned code.
i see to ways to get there:
A) move the node store parts out of oak-core because they don't belong
there
as they are a different layer in our original
- jcr (top-bread)
- core (meat with all the validation)
- persistence (bottom-bread, aka mk)
design
B) move the rest out of oak-core and 'redefine' the name 'oak-core' to be
just the persistence (bottom-bread) but no longer representing the meat.
from an architecture point of view A) looks like the desirable
solution for me... B) looks really confusing to me but might be suited
to address the concerns raised by those that fear that the node store
implementations are too unstable and too heavily worked on.
my concern with B) is that we will end up just doing what we currently
try to avoid: heavily refactor and restructure the meat-layer and
possibly ending up with way too many modules.
as far as access control (and the other security related areas)
is concerned, you can be assured that i will keep an eye on it...
don't worry :-)
kind regards
angela
On 06/08/15 12:25, "Thomas Mueller" <mu...@adobe.com> wrote:
>Hi,
>
>>
>>OTOH if one module does storage and indexing and access control and
>>monitoring for example it's too much IMO, that should ideally be four
>>modules.
>
>Again, what would be the benefit of having many Maven projects? Besides, I
>don't think we could easily move all of access control to one Maven
>project, because access control is a cross-cutting concern. Monitoring, I
>don't think we do much of that right now.
>
>>in Sling we are only testing very few combinations,
>>actually just one combination per release.
>
>Good to know! I still don't quite understand why you have many projects
>then... what is the driver to create smaller and smaller projects?
>
>Regards,
>Thomas
>
Re: Modularization
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>
>OTOH if one module does storage and indexing and access control and
>monitoring for example it's too much IMO, that should ideally be four
>modules.
Again, what would be the benefit of having many Maven projects? Besides, I
don't think we could easily move all of access control to one Maven
project, because access control is a cross-cutting concern. Monitoring, I
don't think we do much of that right now.
>in Sling we are only testing very few combinations,
>actually just one combination per release.
Good to know! I still don't quite understand why you have many projects
then... what is the driver to create smaller and smaller projects?
Regards,
Thomas
Re: Modularization
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Aug 6, 2015 at 11:50 AM, Thomas Mueller <mu...@adobe.com> wrote:
> ...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....
I agree, besides doing just one thing a module should be as complete
as possible. What you're showing is a typical example of too small
modules.
OTOH if one module does storage and indexing and access control and
monitoring for example it's too much IMO, that should ideally be four
modules.
>
> Testing is always a challenge, and testing many possible combinations of
> bundles in different version is just not possible....
Also agreed, in Sling we are only testing very few combinations,
actually just one combination per release.
-Bertrand
Re: Modularization
Posted by Thomas Mueller <mu...@adobe.com>.
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
Re: Modularization
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Aug 6, 2015 at 10:51 AM, Francesco Mari
<ma...@gmail.com> wrote:
> ...What is your take on modularisation?..
>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.
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.
You do need strong integration tests to verify that a given
combination of modules works then, but that also helps make your
project better. And you don't need to bless many combinations, maybe
just define a release cadence for a known good combination of modules
that becomes the next release.
-Bertrand
Re: Modularization
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>- Move NodeStore implementations into their own modules.
I think the time spent on that would be better used trying to improve
modularization *within* oak-core, and for example move the DocumentMK to
the test package, improve javadocs, get rid of unused methods and classes,
and so on.
>- Leverage OSGi sub-systems to hide Oak's private parts (i.e. all that
>component we export just for ourselves).
I agree here.
>- Fine tune over time, evaluate what worked and what not and follow up
>from there.
I agree. Let's do one step at a time.
Regards,
Thomas
Re: Modularization
Posted by Michael Dürig <md...@apache.org>.
On 6.8.15 10:51 , Francesco Mari wrote:
> What is your take on modularisation?
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.
Michael