Re: [Geotools-gt2-users] geotools library as an OSGI plugin

[Jody G. <jod...@gm...>]

My current idea would be:
> 
> - to have a dedicated, OSGi specific, GeoTools module (say gt-osgi /
> org.geotools.osgi) to deal with all the black magic that will be
> required. This module depends from the OSGi APIs (and hopefully that
> is the only one)
Interesting; I had a slightly related idea (based on NetBeans NLookup). Define what we need out
of a plugin lookup system; and allow applications to register their preferred system with the GeoTools
class. 

We do the same technique for handling loggers.

For loggers we were able to get away with a compile time dependency; and then have GeoTools ship out of the box
to work with different logging systems if they are available. If possible I would like to take the same approach with this
one and avoid a gt-osgi module.
> - gt-osgi registers to the BundleContext the appropriate listeners in
> order to be notified when new bundles are added/removed to/from the
> OSGi runtime
> - when a new bundle is added, gt-osgi scans it, looking for
> META-INF/service/* files and it reads/interprets them
> - this information is then passed to the "core" module where all
> services are registered.
Now one thing we will need to do (in the proposal, and in these emails) is slow down a little bit for the geotools community. Previous proposal
were "opaque" if the reading audience did not have a background in OSGi. :-)

References:
- http://www.osgi.org/javadoc/r4v42/org/osgi/framework/BundleContext.html
- http://www.knopflerfish.org/osgi_service_tutorial.html
- http://en.wikipedia.org/wiki/OSGi
- http://confluence.atlassian.com/display/PLUGINFRAMEWORK/OSGi,+Spring+and+the+Plugin+Framework

I was hoping we could register proper bundle service entries in the manifest; and have the osgi lookup mechanism recognise them? It could be I am saying the same thing as you; but with my limited knowledge of OSGi there is a gap in my understanding :-)

I did not really want to read the META-INF/services/* files if we could avoid it; I would rather use that information at compile time to register the services in the generated MANIFEST.MF. This way applications could use the GeoTools jars out of the box?

I looked for an example of how to declare a service in the MANIFEST.MF but could only find examples of how to use an existing service.

Could you (on the proposal page or email) show an example with a GeoTools class. Something simple like FunctionFactory would work well; and we could use it when we write test cases for the integration step.
> The last remaining question is how this information is passed.
> An idea could be to have gt-osgi be a fragment of gt-"core" (sorry, I
> don't remember the precise name of this module).
The module is the lowest implementation on the totem pole - gt-metadata. It contains the GeoTools class
which currently we can use to add in "FactoryIterators". This is our existing technique to allow osgi or spring
content to register themselves with the GeoTools library - but near as I can tell it has not been used.
>  It would then simply call an appropriate static method, or any other mechanism...
> Something cleaner (without static calls) would be to have the "core"
> module publishing a service, either via an Activator or via a Blueprint configuration.
> > We should get an action group together and push for it.
> I'm in. (but I don't have much time nor resources :)
I will try and scare up some interested parties from udig-devel; my next project is working on wps / process - but I will be 
happy to review proposals and code.

Jody