jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edgar Poce <edgarp...@gmail.com>
Subject Re: Internal package dependencies in Jackrabbit
Date Thu, 22 Sep 2005 16:54:33 GMT
On 9/22/05, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> 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.
>

I'm not saying that a generic framework should be placed in the core,
I'm just saying that it would be nice to have reusable components that
could be used for building such a framework somewhere else.

> 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.
>
> cheers
> stefan
>
> >
> > 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
> >
>

Mime
View raw message