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

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

> Sounds like you are making great progress Mathieu, good stuff. Some comments
> inline.

And, as discussed in Barcelona, I still keep in mind as a long-term
goal to be able to have an OSGi-based GeoServer.

This would make it easier to flexibly combine various technologies
(e.g. Spring Security), would allow to dynamically load fixes on a
running server, to have various versions of a given implementation
coexist in the same runtime (e.g. stable / beta), etc.

>> Question: would we consider impacting the code in order to reduce (or
>> completely remove) that kind of packages declared in many modules?
>
> I think long term it would be ok to try to enforce the policy that we make
> packages unique to modules/bundles. But in any attempt to do so we will have
> to worry about maintaining backwards compatibility... and any packages that
> we want to move we will have to first go through the normal deprecation
> cycle. So a possible way forward would be:
>   1. identify all the packages/modules now that are in violation
>   2. figure out how to move/reorganize all the package structures, and do
> all the necessary deprecations on the current 8.x branch
>   3. once 9.x realizes that will be the first osgi compatible branch

In many cases, maintaining backward compatibility with non-OSGi
runtimes (that is based on a linear classpath) will not be that
difficult. So we could follow the approach you suggest but still have
an OSGi-compatible branch earlier.

In many cases, we can simply keep the old classes where they are,
deriving from the new ones, and OSGi would only expose the new ones.
But a classic linear classpath would still find the old ones.

In the case of gt-epsg-hsql there is also the issue of the visibility
of some classes/methods/fields from gt-referencing.
I don't know how critical it is to keep that kind of visibility restrictions.

More generally, there are two nice things with OSGi, which IMHO
justify the effort.
First is the dynamic features (as I described above when dreaming of
an OSGi GeoServer), second is how it underlines the dependency
structure of your component/module-based application or framework.
After the initial pain of ensuring that an existing framework would
fit, it enforces by construction that you have well defined
dependencies and APIs between the modules. It makes some structural
problems appear much earlier (e.g. cyclical dependency between
modules, etc.) when it is easier to deal with them.