Re: [Geotools-devel] OSGi: first simple example with referencing factories working

[Mathieu B. <mba...@ar...>]

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?