> > so while i agree that code duplication is not desirable, i would
> > (until the situation with the helper classes is resolved) suggest
> > to anyway duplicate the code to maintain the independence from
> > jackrabbit.
> i seems, you did not get my point: i suggested to have the
> very common utility classes present in the jackrabbit core
> in some separated package, so everyone can make use
> of it without introducing unnecessary dependencies to the
> core.
of course, i think we had no misunderstanding there.
as you can see above my statement was not about your
suggestion, but about the current state of the jackrabbit
core.
as i tried to explain in my prior post, when it comes to
deciding between a dependency to jackrabbit or a duplication
of helpers (as it stands right now), then i would say that
the dependency on jackrabbit for right now is the worse
choice.
or to generalize jukka's statement:
"... by design no dependencies to Jackrabbit."
> i had some of the utilities duplicated in the jcr-server
> and i ended up removing most of them, because i was
> tired of running after the changing api/jackrabbit.
>
> so: what are the arguments against having a general
> pool for common utilities in jackrabbit?
>
> - valuehelper
> - constants
> - iteratorhelper
> - etc...
>
> those are things i would even expected to be part of
> the api, since probably everyone building its
> jsr170 impl will have those kind of helpers.
of course i categorically disagree with the idea that
every helper/convenience method that could be useful
should be a part of the specified api (especially of a
v1.0 api) for obvious reasons.
regards,
david
|