Interesting, that FactoryIterator thing adds a new dimension to the discussion. It might offer a rather seamless migration path from poor man's META-INF service registry to the OSGi service registry.
1) Osgify all Geotools libraries as outlined in my wiki additions. 2) DO NOT worry about buddy classloading, you no longer need it. (At least not for this purpose - I'm not sure if the classloader gets (ab)used elsewhere in Geotools...) 3) Add a BundleActivator to each bundle which registers each factory implementation as an OSGi service for the factory interface, using the implementation class name as an additional parameter. This will not break anything when using Geotools outside of OSGi, there is just an additional class in the JAR which will never get loaded. (You do get a compile time dependency on OSGi, of course.) 4) Extend FactoryRegistry.scanForPlugins() to also scan the OSGi service registry for services of the given factory. (Move this code to a helper class which will throw an exception on instantiation if there is no OSGi environment, which you can simply catch and ignore, since in that case, all factories should have been found by the traditional lookup method.) 5) Encourage Geotools users to move to OSGi and directly use the service registry. The Factory SPI system will become deprecated, but will continue to work. 6) Decades later, drop the deprecated Factory SPI code from Geotools. ;-) This still does not solve the split packages issue, so you have to use Require-Bundle and not Import-Package for dependencies between Geotools bundles, but that would be acceptable for most users, I think. For third-party dependencies, however, you should use Import-Package, to avoid tying Geotools users to a particular bundle provider. This is probably not quite the original idea of the FactoryIterator, and I think you do not even need it with this approach: instead of registering a FactoryIterator with the old-style FactoryRegistry, you simply rely on the OSGi service registry to do the job. Harald -----Ursprüngliche Nachricht----- Von: [EMAIL PROTECTED] im Auftrag von Jody Garnett Gesendet: Fr 12.09.2008 18:31 An: User-friendly Desktop Internet GIS Cc: geotools-devel@lists.sourceforge.net Betreff: Re: AW: [udig-devel] Re: External dependenciesin net.refractions.udig.libs So that is useful background information ... what is your recommended course of action - and can we start the process of fixing GeoTools to be more friendly in an OSGi environment? Based on you page it sounds like: - add information to MANIFEST.MF - add BuddyPolicy to work around scanForPlugins() Factory SPI requirements GeoTools has the ability to add a "FactoryIteator" to our registries; that was the intended way to let GeoTools make use of OSGi service registry. Jody Wellmann, Harald wrote: > See http://docs.codehaus.org/display/GEOTDOC/03+GeoTools+and+Eclipse+or+OSGi > for a discussion of workarounds (I added some new material last night.) > > ******************************************* innovative systems GmbH Navigation-Multimedia Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980 ******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
