GeoTools

Make Geotools JARs OSGi compliant

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: 2.7.6
  • Component/s: admin
  • Labels:
    None

Description

Geotools libraries are not directly usable in an OSGi environment. This affects not only uDig (based on Eclipse RCP which in turn is based on OSGi) but also any potential clients of Geotools which are OSGi based.

uDig currently resorts to putting all required Geotools libraries and their external dependencies into one giant bundle net.refractions.udig.libs. This is a major problem for the following reasons:

  • It defeats the purpose of modularization.
  • This approach works for uDig itself, but not for any client project developing components which have to work both with or without uDig.

Rather than leaving it up the client to osgify Geotools according to their needs, it would be preferable if the Geotools distribution were OSGi compliant.

This can be achieved by changing the Maven POMs and the build process, without any changes to Java sources. See

http://docs.codehaus.org/display/GEOTOOLS/Add+bundle+information+to+jar+manifest

for a detailed proposal.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -
I'm not against this change, in principle, but since none of the GeoTools developers except the uDig people is making any use of OSGI today, make sure you find someone that:
* can do all the job today
* can maintain it over time
* can earn the trust of all module maintainers enough to perform changes on their modules (today for doing the job, and tomorrow for keeping it up to date)
Show
Andrea Aime added a comment - I'm not against this change, in principle, but since none of the GeoTools developers except the uDig people is making any use of OSGI today, make sure you find someone that: * can do all the job today * can maintain it over time * can earn the trust of all module maintainers enough to perform changes on their modules (today for doing the job, and tomorrow for keeping it up to date)
Hide
Permalink
Andrea Aime added a comment -
This plugin, if working, could be of help:
http://mavenosgiplugin.berlios.de/
Show
Andrea Aime added a comment - This plugin, if working, could be of help: http://mavenosgiplugin.berlios.de/
Hide
Permalink
Tisham Dhar added a comment -
The defacto standard for adding OSGi bits to the manifest is currently the Apache Felix osgi plugin based on bnd. For Eclipse users using m2eclipse the conversion process can staged through bndtools - http://njbartlett.name/2011/03/23/towards-maven-support-in-bndtools.html . We are looking at using the OSGi modular system to promote collaboration for our desktop vis platform, similar in vein to UdigLite. I will do the legwork of dragging Geotools into the OSGi world, Harald has already gone some distance on the repos in Berlios, which I have tested.
Show
Tisham Dhar added a comment - The defacto standard for adding OSGi bits to the manifest is currently the Apache Felix osgi plugin based on bnd. For Eclipse users using m2eclipse the conversion process can staged through bndtools - http://njbartlett.name/2011/03/23/towards-maven-support-in-bndtools.html . We are looking at using the OSGi modular system to promote collaboration for our desktop vis platform, similar in vein to UdigLite. I will do the legwork of dragging Geotools into the OSGi world, Harald has already gone some distance on the repos in Berlios, which I have tested.
Hide
Permalink
Harald Wellmann added a comment -
Tisham, I assume you mean the maven-bundle-plugin from Apache Felix.

This was one of the options I tried and dismissed when I started geotools-osgi. The plugin generates Import-Package statements by default, and the defaults just don't work due to the large number of split bundles in Geotools. I'm somewhat out of touch with Geotools currently, but if the codebase hasn't been refactored substantially within the last year or two, the Maven Bundle plugin will not do the job.

Anyway, creating OSGi manifest headers for Geotools artifacts is the easiest part of the problem. The harder part is all the factories relying on META-INF/services. geotools-osgi uses Eclipse Buddy Policies to make things work, which is ugly and only supported on Equinox, but it was good enough for us at the time.

A while ago, I came across the SPI Fly component from Apache Aries (http://aries.apache.org/modules/spi-fly.html) which provides a bridge from META-INF/services to OSGi using byte code weaving. This sounds rather interesting and might be the way to go...
Show
Harald Wellmann added a comment - Tisham, I assume you mean the maven-bundle-plugin from Apache Felix. This was one of the options I tried and dismissed when I started geotools-osgi. The plugin generates Import-Package statements by default, and the defaults just don't work due to the large number of split bundles in Geotools. I'm somewhat out of touch with Geotools currently, but if the codebase hasn't been refactored substantially within the last year or two, the Maven Bundle plugin will not do the job. Anyway, creating OSGi manifest headers for Geotools artifacts is the easiest part of the problem. The harder part is all the factories relying on META-INF/services. geotools-osgi uses Eclipse Buddy Policies to make things work, which is ugly and only supported on Equinox, but it was good enough for us at the time. A while ago, I came across the SPI Fly component from Apache Aries ( http://aries.apache.org/modules/spi-fly.html ) which provides a bridge from META-INF/services to OSGi using byte code weaving. This sounds rather interesting and might be the way to go...

People

  • Assignee:
    Unassigned
    Reporter:
    Harald Wellmann
Vote (3)
Watch (4)

Dates

  • Created:
    Updated: