GeoTools
  1. GeoTools
  2. GEOT-2105

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

        Hide
        William Voorsluys added a comment -
        Stephane,

        I would definitely be interested in testing out your bundles and having a look at the code.
        Could you point me to your code, possibly in your fork of Geotools in Github? We could work together to solve of the drawbacks you mentioned.

        If you're having trouble with the mailing list, feel free to contact me directly on williamvoor AT gmail DOT com. On that note, make sure you're sending your e-mails the list from the exact address you subscribed, or try posting through Nable at
        http://osgeo-org.1560.x6.nabble.com/geotools-gt2-users-f4317834.html

        Show
        William Voorsluys added a comment - Stephane, I would definitely be interested in testing out your bundles and having a look at the code. Could you point me to your code, possibly in your fork of Geotools in Github? We could work together to solve of the drawbacks you mentioned. If you're having trouble with the mailing list, feel free to contact me directly on williamvoor AT gmail DOT com. On that note, make sure you're sending your e-mails the list from the exact address you subscribed, or try posting through Nable at http://osgeo-org.1560.x6.nabble.com/geotools-gt2-users-f4317834.html
        Hide
        Stephane Wasserhardt added a comment -
        "Draft" version of a geotools bundle.
        Show
        Stephane Wasserhardt added a comment - "Draft" version of a geotools bundle.
        Hide
        Stephane Wasserhardt added a comment -
        I just attached a zip file containing a simple maven (eclipse) project.
        I didn't take the time to :
        - Remove the reference to the parent pom (which contains nothing useful).
        - Remove references to my company named "Magellium" : it's only mentionned in the pom.xml file and in the project's directory name.

        Everything is in the pom file !

        We recently added specification of dependencies versions :
        You can see multiple maven properties specifying versions (jts.version, jai.version, etc.) which are then used to enforce the right dependencies versions in the generated Import-Package directives (we previously only had "geotools.version" property).
        This is a work in progress and some dependencies don't have the right versionning (like jgridshift).

        We are planning to remove some of these dependencies from the geotools bundle (and have them in separate bundles) in the future ; but we didn't put any deadline to perform it yet.

        Concerning my problems with the mailing list, I think the problem is that the subscribtion email adress is an alias for the one that I use to send mails...
        I'll try again soon after changing my account settings.
        Show
        Stephane Wasserhardt added a comment - I just attached a zip file containing a simple maven (eclipse) project. I didn't take the time to : - Remove the reference to the parent pom (which contains nothing useful). - Remove references to my company named "Magellium" : it's only mentionned in the pom.xml file and in the project's directory name. Everything is in the pom file ! We recently added specification of dependencies versions : You can see multiple maven properties specifying versions (jts.version, jai.version, etc.) which are then used to enforce the right dependencies versions in the generated Import-Package directives (we previously only had "geotools.version" property). This is a work in progress and some dependencies don't have the right versionning (like jgridshift). We are planning to remove some of these dependencies from the geotools bundle (and have them in separate bundles) in the future ; but we didn't put any deadline to perform it yet. Concerning my problems with the mailing list, I think the problem is that the subscribtion email adress is an alias for the one that I use to send mails... I'll try again soon after changing my account settings.
        Hide
        Stephane Wasserhardt added a comment -
        I forgot the most interesting part : the SPI bridge.
        I attached two files :
        1) GeotoolsSPIServiceRegistrar.java
        2) org.geotools.spi.GeotoolsSPIServiceRegistrar.xml

        The first one is the bridge implementation. You can create a bundle with only this class, or directly add it to the Geotools OSGi bundle I already provided.
        If you use Bnd (BndTools under Eclipse) to build the bundle, and set the bnd file to use Bnd annotations for Declarative Services, you will not need the second file, everything will be generated for you by BndTools using the Bnd annotations in the file
        If you don't use BND tools (Eclipse PDE for instance), you need to add the second file to the project bundle (usually in a "OSGI-INF" folder) and reference it in your bundle manifest (MANIFEST.MF file) using the following directive :
        Service-Component: OSGI-INF/org.geotools.spi.GeotoolsSPIServiceRegistrar.xml

        When OSGi declarative services starts, the MANIFEST is read, and indicates the XML file. The XML file is loaded, and registers the GeotoolsSPIServiceRegistrar class as an OSGi Component. At this point, every OSGi bundle which declares (using Declaratives services or manual registration) an implementation of a Geotool's SPI will be referenced by the GeotoolsSPIServiceRegistrar, and automatically added to the GeoTools SPI ServiceRegistry.
        So there is no difference from a user perspective wether a SPI implementation is loaded through Java SPI mechanism or through OSGi service registry.
        Show
        Stephane Wasserhardt added a comment - I forgot the most interesting part : the SPI bridge. I attached two files : 1) GeotoolsSPIServiceRegistrar.java 2) org.geotools.spi.GeotoolsSPIServiceRegistrar.xml The first one is the bridge implementation. You can create a bundle with only this class, or directly add it to the Geotools OSGi bundle I already provided. If you use Bnd (BndTools under Eclipse) to build the bundle, and set the bnd file to use Bnd annotations for Declarative Services, you will not need the second file, everything will be generated for you by BndTools using the Bnd annotations in the file If you don't use BND tools (Eclipse PDE for instance), you need to add the second file to the project bundle (usually in a "OSGI-INF" folder) and reference it in your bundle manifest (MANIFEST.MF file) using the following directive : Service-Component: OSGI-INF/org.geotools.spi.GeotoolsSPIServiceRegistrar.xml When OSGi declarative services starts, the MANIFEST is read, and indicates the XML file. The XML file is loaded, and registers the GeotoolsSPIServiceRegistrar class as an OSGi Component. At this point, every OSGi bundle which declares (using Declaratives services or manual registration) an implementation of a Geotool's SPI will be referenced by the GeotoolsSPIServiceRegistrar, and automatically added to the GeoTools SPI ServiceRegistry. So there is no difference from a user perspective wether a SPI implementation is loaded through Java SPI mechanism or through OSGi service registry.
        Hide
        Frank Gasdorf added a comment -
        Forks of GeoTools library that already have OSGI'fied modules : https://github.com/HGitMaster/geotools-osgi
        and the project Harald created 5 years ago : http://developer.berlios.de/projects/geotools-osgi/

        IMHO (PS: I agree Harald's suggestion to use spifly), I see two parts to get a bundles for each GeoTools modules running in an OSGi environment.
        First : use felix maven plugin to generate MANIFEST.MF files and add Metadata for Apache Aris Spifly -> bundle names have the pattern <gt-module-name>-bundle-<version>.
        Second: In OSGi environments its required to have spifly core modules started with an early start level. It passes SPI classes to the registry.

        @Jody : Would we get IP/License issues with Apache License 2.0 at LocationTech? Could be a great option to have several different features for different catalog file formats/services plugins/bundles rather than using a big bundle with all GeoTools libs bundled together.
        Show
        Frank Gasdorf added a comment - Forks of GeoTools library that already have OSGI'fied modules : https://github.com/HGitMaster/geotools-osgi and the project Harald created 5 years ago : http://developer.berlios.de/projects/geotools-osgi/ IMHO (PS: I agree Harald's suggestion to use spifly), I see two parts to get a bundles for each GeoTools modules running in an OSGi environment. First : use felix maven plugin to generate MANIFEST.MF files and add Metadata for Apache Aris Spifly -> bundle names have the pattern <gt-module-name>-bundle-<version>. Second: In OSGi environments its required to have spifly core modules started with an early start level. It passes SPI classes to the registry. @Jody : Would we get IP/License issues with Apache License 2.0 at LocationTech? Could be a great option to have several different features for different catalog file formats/services plugins/bundles rather than using a big bundle with all GeoTools libs bundled together.

          People

          • Assignee:
            Unassigned
            Reporter:
            Harald Wellmann
          • Votes:
            5 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: