jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: webdav suggestion
Date Wed, 18 May 2005 13:04:53 GMT
David Nuescheler wrote:
>>I agree there, in our implementation we had to make more or less the
>>same utilities classes.

> it is obvious that many new implementation will have to solve the 
> same problems. so i am not surprised at all that similar 
> "implementations" come up with similar code. i guess it is not the
> idea of an api to also supply the "sdk" with a number of useful
> building blocks for builing the implementation. that clearly is the
> job of the RI. i think we clearly have to separate the concerns 
> here.

perfect. even better if you agree that this the job or an
RI :).... as long as i don't have to feel ashamed due to
duplicate code (and don't have to argue during month about
issues that you consider to be the job of an RI) :)

could anyone of the ri-team give an opinion about the
idea of a utility package outside of the core?

when looking at the complete jackrabbit code i got the
feeling that jukka already did some work... if the
'modules' hiding the effective package structure
are ignored, the jackrabbit package structure currently
looks as follows:

+ org
   + apache
     + jackrabbit
       + core       { the complete ri}
          + value   { everything regarding values }
          + util    { general utilities including uuid }
       + name       { hmm.... yet another QName and Path classes }
       + iterator   { additional iterators ? }
       + session    { additional session helpers ? }
       + value      { additional value classes ? }


hmm.... actually, i don't feel so happy with that.
i focus on the core, ignoring that additional code present
those additional packages present in the contrib\jcr-ext module,
but looking simply at all the packages present, i would
feel pretty much confused.


View raw message