Wellmann, Harald wrote:
There is nothing wrong with that, only there is a conflict with the
OSGi recommendation "no split packages". So if you want your derived
classes to reside in a separate bundle (which enables you to leave out
the bundle from your deployment if you don't need it) then your
package interface becomes a bundle interface, and so it should be public.
The real question is: Geotools is now partitioned into plain old libraries or
JARs, some of which are optional. uDig packs all Geotools libs into one bundle
(together with other third party stuff). I've tried so far to build one bundle
per lib. But is this really the optimum partitioning for OSGi?
Even if we stick with one bundle per lib, it would be a good thing to restrict
exports. For simplicity, I've simply exported all existing packages from each
bundle. Without the Geotools expertise to tell at glance whether or not a given
package is only used within the same package, I wouldn't have any other choice,
except using a static analysis tool like Classycle.
My personal feeling is one bundle per lib; and to restrict exports. In
the case where a super class is being exported I think geotools could
fess up to it by making the class public. I understand that there is
some back door to let exception to the rules apply. It would be nice to
make public packages (for client code to depend on); and implementation
packages (for implementors to extend) but that may not be possible....
I do not understand the difference between bundle and package
... it sounds like you are talking about something very specific.
Well, a package is just a plain old Java package, and a bundle is an OSGi bundle,
Okay cool - I was thinking you were introducing new terminology.
i.e. a JAR with some special manifest headers which can be deployed into any
OSGi framework. Usually, a bundle contains one or more Java packages, and a
bundle also is an architectural unit with its own visibility rules.
(Unfortunately, Eclipse has blurred the terminology by calling bundles
plug-ins.)
Actually, this is the whole point why I use OSGi in my projects. Java packages
are too fine-grained to act as architecture building blocks, and once a package
has public classes, you cannot prevent anyone from using them anywhere they
like, so you are bound to end up with a mess of building blocks with cyclic
dependencies.
OSGi gives you a component model with just adequate granularity and it prevents
cyclic dependencies from the start. (At runtime, you cannot resolve a bundle
with cyclic dependencies. If you work with Eclipse PDE, this check already
happens at compile time.)
The component model is about 5 % of OSGi functionality, and even if you don't
use all the rest, this alone is very valuable I think. Classloader issues are
the only downside to it, but there is always a price to pay...
Nifity; so can we write this up for the GeoTools community to ponder? I
am afraid we missed todays IRC meeting (this would of been a good
discussion point).
That is an amazing amount of work - thanks for the
dedication. You may want to start your wiki page with just
the contents of your email; it is very clear and the GeoTools
community already has some background knowledge of the problem.
Oh well, as I said, I started using Geotools and uDig in my own project, and
I'm trying to keep my house clean, if I can ;-) Geotools is not the only
external dependency I had to osgify manually, and of course it always better
when things get cleaned up at the source.
I'm going to write that wiki page and post the link on this list.
Regards,
Harald
Thanks; eventually I would like to move discussion over to the geotools
library and effect some change.
Jody
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
