>> - since we use OSGi as our deployment platform, I first need to >> repackage everything as OSGi bundles (common enterprise libraries are >> provided by SpringSource, bur not geotools, geoapi, jts, etc.) => this >> is quite a bit of work and I don't want to do it on a moving target > > Can you help us! I so want to include the OSGi manifest information in the > geotools jars - and have a proposal here. I just lack volunteers (even myself > cannot volunteer because I don't honestly know what is needed).
Hi Jody, to put it shortly: sure I'll be happy to help. I'm leaving next Monday for a mapping / technologies (geotools among them) testing trip to Moldova and Ukraine for two weeks, so I won't be able to start anything before end of May / start of June. While we do some RCP development, our focus is mostly server side OSGi using Spring Dynamic Modules (aka. Spring OSGi) and more generally integrating the various Spring portfolio projects [1]. But work on this would probably greatly benefit the RCP community as well. ## Background During the last few years, we have gathered a lot of experience with OSGi and especially integration with Maven. We try to do it using as many standard tools and approaches as possible, especially the excellent Bundle Maven Plugin of the Felix project: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html For some tasks we have developed a custom Maven plugin (considered stable): http://www.argeo.org/projects/maven-plugins/site/maven-argeo-osgi-plugin/plugin-info.html During the last few months we have developed an approach to integrate closely with Eclipse PDE, so that all development tasks can be done in a pure OSGi settings and Maven is used "only" for build but also for generating the target platform (<=> the set of OSGi bundles that PDE use as dependencies), which is critical when you have a lot of dependencies. OSGi allows us to maintain a kind of "Java distribution" of the standard third parties, similar to a Linux distribution (one of our goal is indeed to better integrate with Linux package based approach): http://www.argeo.org/projects/distribution/site/1.0.3/versions-all/dependency-management.html (we plan to have at least part of GeoTools and its dependencies in v1.0.4) ## Geotools and OSGi I think that GeoTools could greatly benefit from an OSGi approach, due to its extremely modular nature. What I have done so far is (apparently like uDig) is to package all modules I was interested in in one bundle, merging the META-INF/services files: https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.osgi/geotools/pom.xml (WARNING: experimental / PoC config, just accept the self-signed certificate) It works ok so far, even with the QuickStart UI started from an Spring OSGi based setting. In order to fulfill the task described in [2] (your link), one could use the Maven Bundle Plugin (see above) => it generates the MANIFEST.MF based on the introspection of the generated classes. We use it massively for our low level libraries (higher level apps are developed with MANIFEST maintained by hand in PDE, so that the developers don't need to know Maven). The nice thing is that you can have some generic config in a parent POM (example taken from one of our projects): <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>${version.maven-bundle-plugin}</version> <extensions>true</extensions> <configuration> <manifestLocation>META-INF</manifestLocation> <instructions> <Bundle-Version>${project.version}-r${buildNumber}</Bundle-Version> <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> <_removeheaders>Bnd-LastModified</_removeheaders> </instructions> </configuration> <executions> <execution> <id>bundle-manifest</id> <phase>process-classes</phase> <goals> <goal>manifest</goal> </goals> </execution> </executions> </plugin> In your case your could simply replace: <Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName> by <Bundle-SymbolicName>org.geotools.${pom.artifactId}</Bundle-SymbolicName> but I don't know how BND (the underlying library in the plugin) would deal with the '-' in 'gt-'. It may be better to override for each project. You will notice that the MANIFEST.MF is genrated in ${basedir}/META-INF for integration with PDE (as suggested in [2]). The MANIFEST.MF is then just marked as svn:ignore (since it is a derived resource) and the Maven jar plugin is tweaked as follow: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestFile>META-INF/MANIFEST.MF</manifestFile> </archive> </configuration> </plugin> As for a more general compliance of GeoTools with OSGi (discussed here [3], I think) the main issues I see at first sight are: - the many split packages => in OSGi the basic unit is really the package more than the bundle which is just a way to distribute sets of packages: you can then have clear and readable (without tools) dependency graphs in apps with 200+ bundles/modules - the question with loading the external libraries esp. all the ImageIO stuff. I haven't worked on the latter yet. I must say that I'm not a big fan of Eclipse-*Buddy* approach, not only because it is not standard but also because you lose a lot of OSGi rigor and (let's say it) beauty with that. In general, with a bit of thought and with OSGi fragments you can solve most problems. I'll be happy to discuss all this further when I'm back, but this is already food for thought meanwhile... Cheers, Mathieu [1] However we are not into Spring dm Server or Spring STS IDE, due to doubts we have about their licensing and strategies for these products [2] http://docs.codehaus.org/display/GEOTOOLS/Add+bundle+information+to+jar+manifest [3] http://docs.codehaus.org/display/GEOTDOC/03+GeoTools+and+Eclipse+or+OSGi ------------------------------------------------------------------------------ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
