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

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

> The same package in multiple modules is a classic OSGi problem called the
> "split package" issue. The bnd tool provides some directives to mark
> exported packages as split across multiple bundles leaving giving the
> runtime classloader the chance resolve classes in these packages across
> bundles.

Yes, but split-packages (even though in the specifications) are IMHO
more a kind of workaround mostly required in the Eclipse context.

In practice they should really be avoided, they add complexity and
make some underlying issues in the module structure less visible.

I tried to use them to work around the gt-epsg-hsql issue but it did
not work right away, and I did not invest more time in this trail at
this stage.

But I fully agree with you that in the short-term we should use all
what is available to workaround the problems.

> Basically marking exported packages as split and merging them in client
> bundles using require-bundle directive. This is pretty messy and hopefully
> will not result in cyclic dependency issues.

There has been a lot of discussion in the OSGi community around
whether Require-Bundle directives should be used or not. Many people
agree that Import-Package is best practice.
See http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html

But in an Eclipse context this is sometimes unavoidable or way easier:
http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html

(by Argeo, our policy is to use only Import-Package, esp. for
low-level libraries, except in Eclipse RCP/RAP)

Because this is an important point, that we would need to discuss
anyhow, let me illustrate it, first with an example from our
experience and then seeing how it could apply for GeoTools.

We tend to use a lot of packages from the Spring Source Enterprise
Bundle Repository:
http://ebr.springsource.com

They repackage third parties by naming them:
com.springsource.<package root>
e.g. com.springsource.org.apache.commons.io

Sometimes we need to repackage some of these libraries, either because
we need to update them and they haven't yet, or because some of their
metadata do not fit our context (e.g. forcing the version of javax.*
bundles in order to support Java 1.4, whereas we only support Java
1.5+).

Our own repackaged bundles are named:
org.argeo.dep.osgi.<library name>
(for the record, but OT: will probably change soon)

If our apps would use Require-Bundle, they would be broken when we
perform such a change.
With Import-Package, this is completely transparent.

Now let's move to a popular free software library such as GeoTools,
that you want to hack/fork/repackage etc.

The nice thing with Import-Package is that your application just says,
for example: "I want the capabilities provided by
org.geotools.referencing".

It may be provided by the "official":
org.geotools.gt-referencing

but also by:
org.opengeo.org.geotools.referencing
(because they wanted to quickly patch something for a customer)

or by
org.geonode.org.geotools.referencing
(because they use a custom GeoServer)

or by
org.argeo.dep.osgi.geotools.referencing
(because we tweaked the OSGi metadata so that it works well with our
RCP/RAP application)

or
eu.udig.org.geotools.referencing
(because they tweaked the OSGi metadata so that it works well with the
existing code base)

So, to sum up, I think that Import-package is "better" in general, but
especially for free software base libraries.
It unlocks a great strength of free software: you can hack, you can repackage.