On 9/22/05, Edgar Poce <[EMAIL PROTECTED]> wrote: > Hi jukka > > Jukka Zitting wrote: > > > > I tried creating a semi-automated package diagram for Jackrabbit, but at > > least at the moment there seems to be too many interdependencies to > > produce a good overview diagram. The result of a fully automated run can > > be found at http://yukatan.fi/2005/09/jcr/jackrabbit-dependencies.png. :-) > cool ;). > > > > > Some immediate observations: > > > > * Move the QName constants from o.a.j.Constants to o.a.j.name.QName to > > break the o.a.j <-> o.a.j.name dependency cycle. > > > > * Add a BlobFileSystem property to PMContext to break the direct > > LocalFileSystem dependencies in the persistence managers. > > > sound good > > > * Move the PersistenceManager, QueryManager, etc. interfaces and > > associated component classes into one or more separate packages > > (I think this was the idea of the .api proposal) > > > maybe I'm wrong but AFAIK the idea of the api project was to host the > new jcr api and not jackrabbit specific interfaces. However I think it > would be a good idea to move the internal interfaces into one or more > separate packages and reduce the dependencies. I'd like to see the > jackrabbit core components not only as the RI but also like a modular > and extensible toolkit for building custom jcr implementations.
sorry, i disagree. jackrabbit should in my opinion a first class jcr repository. it should be robust, scalable and fast. i don't think that you can accomplish this by also trying to make it into a generic toolbox/framework for building custom jcr implementations. imo we should concentrate on making jackrabbit the best opensource jcr repository. cheers stefan > > br, > edgar > > > What do you think? > > > > BR, > > > > Jukka Zitting > > > > >
