> Wanted to introduce you to Crag from the uDig project - who cheerfully asked > me how geotools / osgi relationship was going. When he last checked in Harald > was working on it (but as you saw on that page Harald left instructions and > thus nothing has happened).
Sorry, I'm kind of busy right now but I keep thinking on this. I'm afraid I won't have much time to code/test anything in the next two weeks, but I hope to find time to to update the wiki before that. > I had kind of a basic / stupid question for you. > > The problem I have in uDig (which has me loading everything into a single > bundle) is that OSGi prevents me from accessing stuff that is not in a > published java package. Including the contents of META_INF/services > > How does this work once we have geotools with correct OSGi manifests? Are we > marking META_INF/services as avaialble? This is far from a basic question and this is/will be our main problem I think. In theory you could export META-INF/services as a package, but if you do it for more that one bundle you don't really know what will be picked up. So I doubt that this is the right approach. When dealing with classloader issues with OSGi, I always try to repeat myself: "No magic... No magic... There is a logic behind this." The first question is "WHO is loading?", that is, which bundle is loading? As you know, each bundle has its own classloader which doesn't 'see' everything. The MANIFEST contains the configuration of this classloader (among other things). The second question is "WHAT is it loading?", that is, which class/resource? In the simple case, you just need to make sure that WHO sees WHAT, typically by adding an Import-Package. But an approach can be to put the required stuff in one single bundle. That is what you are apparently doing for uDig and that is what I did last month when I packaged some GeoTools modules in OSGi. I wrote a small routine in Maven to generate merged META-INF/services files for all the modules and put them under the META-INF/services of the unique jar/bundle containing all the classes. An idea (I come to my point) would be to come back to the basic WHO/WHAT question for the SPI approach. In SPI, there is a 'core component' which scans the available META-INF/services/spi.interface files listing implementations for spi.interface In OSGi, the SPI 'core component', that is the bundle containing the code actually loading the implementations, needs to 'see' the following: * META-INF/services/spi.interface file(s) * the packages containing the implementations of spi.interface So we could try to create a separate fragment for each library using SPI. The host bundle would be the bundle of the library/core component loading. This fragment would: * provide a META-INF/services listing all implementations related to the host bundle * a MANIFEST with an Import-Package listing the packages of these implementations, which in most cases the 'core' SPI bundle doesn't see The problem with this approach is that you create additional jars only to deal with this issue and the information in the META-INF/services file will be duplicated. However I am confident that we could write a small routine in Maven which would dynamically generate the required information from the existing geotools jar. Another way to go (as suggested on the wiki) would be to use the magical OSGi directive for dynamic loading (equinox specific or not). In general I really prefer approaches based on fragments since they are explicit: this is in my opinion one of the strength of OSGi (however painful it is): you explicitly define your dependencies at component level. Another thought I just put here for reference is to see in details what can be done with context classloader (that what I used to have ImageIO working) I think we should do a few test on a small but consistent and representative subset of geotools modules which are using SPI (both geotools internal and from third parties) Which ones would you recommend? Cheers, Mathieu ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
