Hi Tisham, > I have tested the 2.6 and 2.7 monolithic bundles and they pass our OSGi > integration tests which cover the ShapeFileDatastore. Until we get our maven
The problem I had with 2.7 was related to the PostGIS datastore, good to know that it is working in other contexts. > proxy up we are fetching bundles from any OBR's we can locate. You have > plenty of maven-fu already, but in case you are wondering something like > this can generate the repository.xml for the OBR: I generated (manually) an OBR repository for our "release" maven repo: http://maven.argeo.org/argeo/repository.xml Please tell me if it is helpful. I will try to automate this somehow. > If you have an OBR index already, a direct link will be handy for > consumption. I am on demo nexus at the moment contemplating paying for it or > getting the freebie for our TrikeND work. FYI, we are currently working on a (free / open source) generic repository to store maven artifacts, OSGi bundles, but also possibly modules for other programming languages. The idea is to work a lot on the metadata so that different "views" of the same artifacts (Maven, OBR, P2, etc.) can be available. We won't have something production ready soon (we are still in a prototyping phase) but this is a subject we are very interested in. May I ask for which reason you consider purchasing Nexus? What do you expect from it? (compared to the community version or Archiva, etc.) (since this is a bit OT, feel free to answer to me offlist if you find the time) > More on the OSGi migration front can the META-INF services inspector be > sufficiently generalized to track all SPI based things ? Is there are Yes the approach is generic. The only problem is that we need to refresh the registry explicitly. I just don't know how to do it for something else than the referencing factories (where a static method is available). The Lookup approach of Jody should solve this issue (cf. previous mails). Meanwhile, if this is blocking for you, I can try to have another look and see if I cannot hack something in gt-metadata until we get the Lookup stuff. (but that won't be before the end of the week) > general solution ? For the compile/jar assembly time fix - should we add > some more instructions to the Bnd tool and Felix Bnd plugin to map to > OSGI-INF. We already have some code which scans the service files (in order to merge them, e.g. for the monolithic GeoTools bundles). I could pretty easily reuse it so that it generates service definitions under OSGI-INF. For the time being, and due to the limited resources we have, my approach was to focus on the extender approach and have it working, before we evaluate together if it worth trying another approach. I mean, the result will be the same: the factories publishes as OSGi services. A really alternative approach would be to do exactly the same as SPI without using OSGi services and the OSGi lifecycle (RESOLVED -> ACTIVE -> RESOLVED): - scan the service files - instantiate the services with the proper classloader - register them This approach would be pretty easy to implement based on what has been done already for the service approach. This would work around the refresh issue. However that would be a bit sad not to map the GeoTools factories with OSGi services, since they address the same needs. Actually my idea was to try this "static" approach (rather than the OSGI-INF, which is just another, less flexible way, to use the service approach) and make it configurable which one is used (via System properties). The "static" approach would behave exactly like the standard approach (only hiding OSGi constraints) and could therefore be even more transparent to existing apps (no need to decide which bundles to start). > I guess in my enumeration of things I missed the bundle fragment approach > for mushing together classloaders, but bundle-fragments introduce similar > issues to Require-bundle. The host bundle cannot change easily, fragments > are attached to the symbolic-name not packages. I tried a fragment based approach for GeoTools some months ago. As you suspect, this was definitely heavier, less flexible and more difficult than the other approaches we are currently discussing. Cheers, Mathieu PS: TrikeND sounds very exciting. Is there more documentation available? Do you plan to integrate with R? ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Discover what all the cheering's about. Get your free trial download today. http://p.sf.net/sfu/quest-dev2dev2 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
