Hi, >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 stack. 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 so). > 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 Regards, Thomas
