jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: [jr3] One Project
Date Wed, 01 Dec 2010 14:34:29 GMT

Replying here even though my answer concerns a number of messages on
this thread.

Starting small with a single project is probably ok. If we are ready to
split the project into multiple smaller projects later, ok. If we are
not ready, then no.

OSGi vs. non-OSGi... There are OSGi-zealots and anti-OSGi-zealots. So be

Lets put it like this: People run an application in an OSGi framework
and want to deploy Jackrabbit into it. They need OSGi-enabled/friendly
Jackrabbit. There are people not running their application in an OSGi
framework, they don't care for OSGi stuff - as long as Jackrabbit does
not require OSGi to run.

The good thing is: You can have both. Derby does it for example.

So, I strongly suggest Jackrabbit 3 to be OSGi-enabled/friendly.

Of course pluggable stuff must really be pluggable -- ACL functionality
(login modules, access control managers, etc.) come to mind. This means
real API separated package-wise from the implementations.

So coming back to development modules. I think we should separate
development and deployment ?

We develop how we see fit ... in multiple modules (my preference) or in
a single huge, monolithic project.

The result of the development are artifacts and here we are free to
create whatever level or modularization we or our users like. We can
create a lot of small artifacts (libraries, bundles) or a single big one
or both. Look at Groovy, they also do that.

Just my $.02.


Am Montag, den 29.11.2010, 14:01 +0000 schrieb Thomas Mueller: 
> 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.

View raw message