jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Mueller <muel...@adobe.com>
Subject Re: On setting component boundaries in Oak
Date Fri, 09 Mar 2012 14:35:53 GMT

>why does splitting into components slows down anyone? you are
>claiming that this was the case but i can't follow your reasoning
>and would like to understand what exactly would slow you down.

For Jackrabbit 2.x, there are quite many projects. In many cases, when I
want to look up or debug something, I have a hard time figuring out what
project(s) I need to open. I'm looking for code here and here and can't
find it. At some point, I kind of give up using the IDE and go to the
command line to use "grep" to search in which project it could be. Then I
open this project in Eclipse (first I have to do svn up, mvn install, mvn
eclipse:eclipse to get the project up to date as most likely it's not).
Once I'm ready I find out that in fact, what I'm looking for is in yet
another project...

If I have an exception stack trace, I have to open various projects
(possibly with the "right" combination of versions) to go though the call

A really ugly example (I know I have already wrote about that) is that the
*unit* tests for *one* project are written in a *different* project (the
SQL-2 parser). It's quite painful if you have to fix a bug in the parser.

Also, given the "separation" we have in Jackrabbit 2.x, there is a lot of
indirection going on. Many classes don't in fact do something, but only
redirect to another class in another project. I think this is called
"ravioli code". The same with abstract classes and concrete classes. I
know, not in all cases the separation is to blame, but in many cases it is.

>for me many components never used to be a problem. not even multiple
>jcr implementations... but maybe that's only me. i know by heart
>what is where and why.

I don't.

>>Please note there will be quite a lot of common code used in both the
>> transient space and the SPI.
>for example? json utilities? txt-utilities? or what are you
>referring to.

Sure, JSON utilities, String utilities, IO utilities, File utilities,
(hopefully) Jukkas NodeState interface and maybe the NodeState
implementation plus related classes. How can you possibly know in advance
in which project it will end up?

>and yes, for that i would create a commons component

No!!! Help!!! ;-) Initially, we will move stuff around quite a bit as this
is just the way it is when you start developing something. As I wrote,
refactoring is a lot easier if it's in the same project. Also, nobody
except us is ever going to use those components. Those components are not
useful outside Oak. (If there are, we would move them to Apache Commons or

> or try to use
>the current jackrabbit-jcr-commons as an initial solution.

I thought we said we will *copy* code from existing projects, and then
refactor it. That way we don't risk breaking Jackrabbit 2.x


View raw message