jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Diephouse <dan.diepho...@mulesource.com>
Subject Re: [jr3] One Project
Date Mon, 29 Nov 2010 23:13:37 GMT
A couple thoughts on this as a user/occassional Jackrabbit hacker:

   - You should be able to configure Maven to handle code coverage over
   multiple modules. I'm pretty sure Sonar does this.
   - Having one jar for users doesn't necessarily have to imply losing build
   modularity. You can configure Maven to make a bundle jar of all the jars
   which is often a nice thing for users (Spring does this for instance)
   - I've never found the build modularity to be a problem as a developer
   (I've made a few Jackrabbit patches). Since I know Maven I've been able to
   dive into the build with no issues because it's pretty standard. Also, I
   almost never go browsing through package structures, I just type in the
   class name in Eclipse because it's much faster that way.
   - I think there is a lot of value in keeping the build modular because it
   keeps the code clean and interdependencies at a minimum. Jackrabbit code is
   very clean and well laid out, making it easy to hack.
   - We as a company don't use all the Jackrabbit modules, so it's nice to
   only have to use the modules we need. Things like WebDAV or OCM aren't
   necessary for what we're doing.

Dan

On Mon, Nov 29, 2010 at 6:01 AM, Thomas Mueller <mueller@adobe.com> wrote:

> I know the reasons for this are historical, and I don't want to change
> things for Jackrabbit 2: Jackrabbit 2 consists of many distinct projects.
> For me, this is just far too many, the complexity is overwhelming even for
> me as a developer of Jackrabbit. I guess it's even worse for users and
> potential committers. One project only contains one(!) class. In some cases,
> the code for a feature are spread into different projects. In one cases
> (that I know of), the unit tests (not just integration tests) for a feature
> is in a different project than the implementation. In my view, using the
> same architecture for Jackrabbit 3 would make developing Jackrabbit 3 very
> inefficient. It increases build time and makes code coverage results
> partially meaningless. As we have seen multiple times, it is also a pain for
> users, because he has to add multiple Jackrabbit jar files to his project.
> There is a risk to combine Jackrabbit jar files that don't work together. I
> don't know a similar projects that consists of that many projects: Lucene is
> one project and jar file (lucene-core), and Apache Derby, HSQLDB, and H2 are
> all one project. In my view, splitting Jackrabbit 3 into multiple projects
> doesn't help anybody at all (not the user, not the developer, and not the
> tester).
>
> But for Jackrabbit 3, I suggest to keep all source "core" code in one
> project, and create one jar file, until we have a good reason to split it
> into multiple projects.
>
> This excludes the TCK (Technology Compatibility Kit)* *of course, which is
> a standalone project independent of Jackrabbit. It may also exclude
> compatibility and performance tests, which are run against multiple versions
> of Jackrabbit. As for remoting (RMI and DavEx) we may want to re-use the
> existing Jackrabbit 2 projects, at least at the beginning, or until we have
> better solutions. It may also exclude "utilities" that are independent of
> the JCR implementation and that are not required within Jackrabbit itself
> (but once Jackrabbit needs the utility, it should be within Jackrabbit).
> What we do need to consider is OSGi, but this doesn't mean we need to split
> the Jackrabbit core *implementation* into multiple projects or jar files.
>
>


-- 
Dan Diephouse
http://mulesource.com | http://netzooid.com/blog

Mime
View raw message