[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [udig-devel] External dependencies in net.refractions.udig.libs
|
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.
> 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.
*******************************************
