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.
yours
angela
