> I have the time and resources (a CSIRO salary) to make non Eclipse bound
That's great news! > So far I count 3 separate attempts at OSGi modifications with SPI getting in > the way - Harald's (UdigLite) and the couple of attempts on this thread. 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) - 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. 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). 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 :) ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
