jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: Internal package dependencies in Jackrabbit
Date Thu, 22 Sep 2005 16:32:42 GMT
On 9/22/05, Angela Schreiber <anchela@day.com> wrote:
> hi
> Stefan Guggisberg wrote:
> >>Jukka Zitting wrote:
> >>>* Move the QName constants from o.a.j.Constants to o.a.j.name.QName to
> >>>  break the o.a.j <-> o.a.j.name dependency cycle.
> eh, that sounds familiar :)
> "[...] for the sake of clarity o.a.j.Constants could be renamed to
>   NameConstants [...] and/or moved to the name package."
> > i don't think that you can accomplish
> > this by also trying to make it into a generic toolbox/framework for
> > building custom jcr implementations. imo we should concentrate on
> > making jackrabbit the best opensource jcr repository.
> from my experience with jackrabbit, i would argue, that
> there is always room for improvement and that an open
> source project should also be the best to be used
> from a developer perspective.

i absolutely agree.

> the blackbox approach
> ("don't look at it") does not make too much sense to me in
> this case.

huh? who was talking about "black box approach"? did i miss
something? there are no black boxes in jackrabbit, all the
source code is there. all i'm saying is that we should imo
concentrate on one goal, i.e. making jackrabbit as robust,
fast & scalable as possible. of course this doesn't mean that
parts of its code base cannot be reused, that was the motivation
behind the former commons subproject. however, imo you can't
have both, *the* generic toolbox/framework for building custom jcr
implementations *and* the most robust, fastest & scalable
opensource jcr implementation, all using the same code base,
as this will lead to substantial compromises on one or the other.
as i said, we should concentrate on one goal, at least so for the
1.0 release.

btw, i remember that jukka mentioned once that he's working
on a framework/toolbox for building custom jcr implementations,
but maybe i am mistaken.


> regarding the api: i have the feeling, that there is the need
> for a more open design and api in various sections of jackrabbit.
> however, this would in my opinion (after working on a jcr
> client) lead to more substancial changes (not only extracting
> a few interfaces). after all, that's what i consider to be
> the future of jackrabbit, in order to make it the best opensource
> jcr implementation :)
> regards
> angela

View raw message