Ok, I'm beginning to see the motivation for this megabundle. >From what I read on the geotools pages about the FactorySPI, and after a brief look at the FactoryFinder sources, I think there's nothing that could not be solved using bundle fragments or Eclipse buddy policies.
> Wellmann, Harald wrote: > > Is there any particular reason for throwing all external > dependencies into this one plugin, other than "haven't got > round to cleaning it up"...? > > > Yes there is ... the reason is the use of the "Factory SPI" > plug-in system by the GeoTools project. This plug-in system > is very old and depends on the ability to read the jar > manifest in order to figure out what services are offered by each jar. > > The eclipse OSGi system has class loader restrictions in > place - only allowing access to Class files in specific > packages. There is no ability to look at the jar manifest > contents - so the Factory SPI plugin system breaks! As far as I can see, the FactorySPI system is based on the META-INF/services approach. In another context, I've managed to make things work with this approach both in a naked Java environment (i.e. putting a bunch of JARs on your CLASSPATH) and in an OSGi environment. My plain old Java extension lookup is based on ServiceLoader.load(Extension.class), which is only available in Java 1.6, but what I see in Geotools FactoryFinder looks much like a user-level implementation of ServiceLoader. To make the ServiceLoader work in an OSGi environment, you only have to make sure that some classes from the factory provider bundles are visible to the factory registry bundle, either via Eclipse buddy classloading, or via bundle fragments (which are OSGi standard and do not only work in Eclipse). > > > It would; however we find OSGi a moving target and until the > "buddly classloader" system actuall works with FactorySPI we > are kind of stuck bundling at least all of the following together: > - geotools > - imageio-ext So is there any particular point where you got stuck with buddy classloading? I'm willing to give it a try with Geotools, but of course there's no point in running into the same traps you already did, so if you could narrow down the problem or give me a pointer to a particular pair of factory registry and provider, that would be helpful. Of course, any solution along these lines would mean that you have to add an OSGi manifest to every Geotools JAR, and if you can't convince the Geotools guys to do that, you'd have to do it yourself. (I'm doing that all the time for using third-party JARs in my OSGi project.) Bundle manifest generation can be automated using the BND tool, which is also available as a Maven plug-in. So in theory, everything should be fine if Geotools only added a few lines to each of their POMs... > > You will notice that we are starting to settle things out on > trunk; in general we want trunk to focus on the RCP customer. > If breaking out the dependencies is something you can now > would be a great time to address the issue. We can set you up > with commit access and so forth. > Sounds interesting. I'll come back to that on a separate thread with some questions on trunk vs. branches. In order to use Geotools and uDig for my project, I would have to osgify everything anyway, and of course it's more useful to everyone if the results get shared with the community. Regards, Harald ******************************************* 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. ******************************************* _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
