jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: webdav suggestion
Date Wed, 18 May 2005 09:50:45 GMT
> > 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

Mime
View raw message