> > 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
