Wellmann, Harald wrote:
Ok, I'm beginning to see the motivation for this megabundle.
From what I read on the geotools pages about the FactorySPI, and after a
brief look at the FactoryFinder sources, I think there's nothing that
could not be solved using bundle fragments or Eclipse buddy policies.
If so that would be great news; what we really wanted to do is have a
situation like:
- org.geotools.main plugin
-- contains gt-main-2.6-SNAPSHOT.jar
-- wants to process a factory SPI (looking for every jar with a
services file for "org.opengis.filter.Function")
And then in ....
- org.geotools.render plugin
-- contains gt-render-2.6-SNAPSHOT.jar
-- has an implementation of CategorizeFunction
-- advertises all the functions it provides with a services file called
"org.opengis.filter.Function"
But we get stuck when...
- org.geotools.main attempts to access the above
META-INF/services/org.opengis.filter.Function file in any other plugin
- it does not get stuck at the class loader boundary; buddy classloaders
works just fine ...
- it gets stuck on the "access restrictions" step; the eclipse class
loader (for Eclipse 3.3) started locking down access to anything that
was not in a "published" pacakge
- ... and there is no way to mark META-INF/services as a "package" to
publish ...
So the facilities you describe sounds good - we would mark the META-INF
folder as part of the bundle?
And we are part of GeoTools - so if you can show me what to do we can
include additional steps in the GeoTools build process. I once worked on
a project called JPox that was OSGi based - but you could load up the
jars and just use them if you were not in an OSGi container.
Links:
-
http://docs.codehaus.org/display/GEOTDOC/05+How+to+write+a+Plugin+-+from+Interface+to+Factory
- http://docs.codehaus.org/display/GEOTDOC/03+GeoTools+and+Eclipse+or+OSGi
Wellmann, Harald wrote:
Is there any particular reason for throwing all external
dependencies into this one plugin, other than "haven't got
round to cleaning it up"...?
Yes there is ... the reason is the use of the "Factory SPI"
plug-in system by the GeoTools project. This plug-in system
is very old and depends on the ability to read the jar
manifest in order to figure out what services are offered by each jar.
The eclipse OSGi system has class loader restrictions in
place - only allowing access to Class files in specific
packages. There is no ability to look at the jar manifest
contents - so the Factory SPI plugin system breaks!
As far as I can see, the FactorySPI system is based on the
META-INF/services approach.
In another context, I've managed to make things work with this approach
both in a naked Java environment (i.e. putting a bunch of JARs on your
CLASSPATH) and in an OSGi environment.
My plain old Java extension lookup is based on
ServiceLoader.load(Extension.class), which is only available in Java
1.6, but what I see in Geotools FactoryFinder looks much like a
user-level implementation of ServiceLoader.
To make the ServiceLoader work in an OSGi environment, you only have to
make sure that some classes from the factory provider bundles are
visible to the factory registry bundle, either via Eclipse buddy
classloading, or via bundle fragments (which are OSGi standard and do
not only work in Eclipse).
It would; however we find OSGi a moving target and until the
"buddly classloader" system actuall works with FactorySPI we
are kind of stuck bundling at least all of the following together:
- geotools
- imageio-ext
So is there any particular point where you got stuck with buddy
classloading? I'm willing to give it a try with Geotools, but of course
there's no point in running into the same traps you already did, so if
you could narrow down the problem or give me a pointer to a particular
pair of factory registry and provider, that would be helpful.
Of course, any solution along these lines would mean that you have to
add an OSGi manifest to every Geotools JAR, and if you can't convince
the Geotools guys to do that, you'd have to do it yourself. (I'm doing
that all the time for using third-party JARs in my OSGi project.)
Bundle manifest generation can be automated using the BND tool, which is
also available as a Maven plug-in. So in theory, everything should be
fine if Geotools only added a few lines to each of their POMs...
You will notice that we are starting to settle things out on
trunk; in general we want trunk to focus on the RCP customer.
If breaking out the dependencies is something you can now
would be a great time to address the issue. We can set you up
with commit access and so forth.
Sounds interesting. I'll come back to that on a separate thread with
some questions on trunk vs. branches.
In order to use Geotools and uDig for my project, I would have to osgify
everything anyway, and of course it's more useful to everyone if the
results get shared with the community.
Regards,
Harald
*******************************************
innovative systems GmbH Navigation-Multimedia
Geschaeftsfuehrung: Edwin Summers - Kevin Brown - Regis Baudot
Sitz der Gesellschaft: Hamburg - Registergericht: Hamburg HRB 59980
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und
loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe
dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and delete this e-mail. Any unauthorized copying,
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
