On Wed, Dec 1, 2010 at 12:15 PM, Bertrand Delacretaz <[email protected]> wrote: > On Wed, Dec 1, 2010 at 11:42 AM, Stefan Guggisberg > <[email protected]> wrote: >> On Tue, Nov 30, 2010 at 1:46 PM, Bertrand Delacretaz >> <[email protected]> wrote: >>> On Tue, Nov 30, 2010 at 11:42 AM, Thomas Mueller <[email protected]> wrote: >>>> ....I think reducing the number of >>>> ...If we include all dependencies (such as Apache Commons jar files) you >>>> would need a special class loader, right? Otherwise there may be conflicts >>>> with if somebody already uses a different version of a Apache Commons >>>> library that Jackrabbit also uses. That would be quite complex I guess, so >>>> I wouldn't do that. Instead, I would just concentrate on having as few jar >>>> files as possible... >>> >>> OSGi solves that problem nicely, >> >> so you can have multiple versions of the same jar/bundle concurrently >> deployed in the same osgi container? > > Yes, either by embedding problematic jars in others and hiding them as > private packages, or by setting the right version numbers in the OSGi > manifests, so that bundles get wired to the right libraries. > > That's in theory, you know how practice goes ;-)
i take that as "in practice, OSGi *doesn't* solves that problem nicely" ;-) cheers stefan > > Anyway, right now my ideal view as a Jackrabbit user would be to get > OSGi-friendly jars of the various Jackrabbit modules (core, indexing, > webdav etc.) to be able to assemble them in my OSGi container, and > replace the ones that I'd like to replace with my own variants. > > Whether the Jackrabbit runnable jar uses OSGi is up to the Jackrabbit > developers, but from the user's point of view I think that's important > - two major users of Jackrabbit are Day/Adobe and Sakai, which both > run on OSGi, and with the current jars replacing/extending some > things is a bit painful. > > -Bertrand >
