Hi, Jörn This affects the customization factories. I have never work with OSGi, so I would follow your instructions. What happens if the class we are trying to load is in another jar? This jar should also export packages?
Thank you William On Fri, Apr 13, 2012 at 8:11 AM, Jörn Kottmann <[email protected]> wrote: > Hi all, > > we have very basic OSGi support currently. We simply export all > the packages we have and don't use any other OSGi features. > This works well for anything we do, expect the places where we > try to access classes by class name, e.g. to load custom factories > via Class.forName(...). Most users will just be happy with that. > > Such calls do not work in an OSGi environment because the class we > try to load is not on "our" class path. > > In OSGi this is done via services and we need to use them if we are running > in an OSGI environment. > > Anyway, OpenNLP needs to work with and without OSGi. > > I suggest that we make OSGi an optional dependency and write code > which can detect if the OSGi classes are there or not. > > To instantiate a user class we would need to do something like this: > - Try to load via Class.forName(...) > - If cannot be found, check if running in an OSGi environment > - If so try to get an OSGi service which provides an instance to the user > class > > Any opinions? > > Jörn > >
