Hello Jody, I gave a first try to integrating the Maven Bundle Plugin with the GeoTools build process. It went pretty well and I could build all the jars with OSGi metadata in their MANIFEST. (more details below)
This was the easy part and now the hard part is to see how we can have a set of modules that can be at the RESOLVED status in an OSGi runtime (that is, all their package requirements are fulfilled). It raises the following challenges: 1 - third party dependencies should also be OSGi bundles => we have already repackaged the most important geotools dependencies (geoapi, geos, java3d, etc.) and many standard dependencies (apache commons, etc.) are available from the Spring Source maven repo https://www.argeo.org/svn/dependencies/trunk/org.argeo.dep.osgi http://www.springsource.com/repository/app/ So I suggest that we first leverage this effort 2 - it will probably require to impact the POM files at the individual module level (typically to set some packages as optional, or import some which were not detected by the BND plugin because they contain resources and not classes, etc.) => how should we proceed? should I send patches? 3 - we have a custom Maven plugin which automatically set up and OSGi runtime and check whether all bundles are resolved => I would of course like to leverage this tool as well during this phase (it won't be required for the build) 4- we will probably have to first put some modules aside if they are to painful and not really critical (I'm thinking of the unsupported ones) => we should identify them on a case by case basis So, an idea could be that we set up a project in our infrastructure (we/our is argeo.org) which would: - checkout geotools code - apply patches - pull out third party dependencies - check the RESOLVED status - (iterate) => the benefit would be that we could then leverage our OSGi tools without creating any dependencies to them in the GeoTools project What is your opinion about this approach? When we have a clean/resolvable set of modules with OSGi metadata, we can move on to the third phase which will be to deal with META-INF/services/*, ImageIO and related stuff. Cheers, Mathieu ## How to generate OSGi metadata with the Maven Bundle Plugin The idea is that the Bundle plugin attaches to the process-classes phase (that is, after the classes have been compiled) and generate the MANIFEST in target/classes bases on the classes (interpreting the bytecode to find out which other classes are needed) The Jar plugin is overridden so that it picks up the generate MANIFEST. These configs are put at the modules/pom.xml level because it did not directly fit with the Collector Maven plugin build. Note: for the time being the Bundle Symbolic Name is org.geotools.gt-<module>. We would prefer org.geotools.<module> but this is not trivial to parse the artifactId and extract the module name. We should see how we can proceed with that. In [GeoTools root]/modules/pom.xml <project> ... <build> <plugins> ... <!-- OSGi manifest information --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-jar-plugin</artifactId> <configuration> <archive> <manifestFile>target/classes/META-INF/MANIFEST.MF</manifestFile> <manifest> <addClasspath>true</addClasspath> </manifest> </archive> </configuration> </plugin> <plugin> <groupId>org.apache.felix</groupId> <artifactId>maven-bundle-plugin</artifactId> <version>2.0.1</version> <extensions>true</extensions> <configuration> <manifestLocation>target/classes/META-INF</manifestLocation> <instructions> <Bundle-Version>${project.version}</Bundle-Version> <Bundle-SymbolicName>${pom.groupId}.${pom.artifactId}</Bundle-SymbolicName> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> </configuration> <executions> <execution> <id>bundle-manifest</id> <phase>process-classes</phase> <goals> <goal>manifest</goal> </goals> </execution> </executions> </plugin> </plugins> ... </build> ... </project> # Patch (from Eclipse) ### Eclipse Workspace Patch 1.0 #P geotools Index: modules/pom.xml =================================================================== --- modules/pom.xml (revision 35636) +++ modules/pom.xml (working copy) @@ -6,7 +6,8 @@ http://www.geotools.org/ Version: $Id$ - ======================================================================= --> + ======================================================================= +--> <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 @@ -71,7 +72,45 @@ </execution> </executions> </plugin> + + <!-- OSGi manifest information --> + <plugin> + <groupId>org.apache.maven.plugins</groupId> + <artifactId>maven-jar-plugin</artifactId> + <configuration> + <archive> + <manifestFile>target/classes/META-INF/MANIFEST.MF</manifestFile> + <manifest> + <addClasspath>true</addClasspath> + </manifest> + </archive> + </configuration> + </plugin> + <plugin> + <groupId>org.apache.felix</groupId> + <artifactId>maven-bundle-plugin</artifactId> + <version>2.0.1</version> + <extensions>true</extensions> + <configuration> + <manifestLocation>target/classes/META-INF</manifestLocation> + <instructions> + <Bundle-Version>${project.version}</Bundle-Version> + <Bundle-SymbolicName>${pom.groupId}.${pom.artifactId}</Bundle-SymbolicName> + <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> + </instructions> + </configuration> + <executions> + <execution> + <id>bundle-manifest</id> + <phase>process-classes</phase> + <goals> + <goal>manifest</goal> + </goals> + </execution> + </executions> + </plugin> </plugins> + </build> On Fri, May 28, 2010 at 11:13, Mathieu Baudier <[email protected]> wrote: >> We were going to look at geotools and OSGi compatibility this month. It does >> look like my schedule is clearing up next week. Should we start discussion >> on Monday? > > Yes, let's start next week. > Monday I'll be back at my desk in Vienna only around noon (CET), so > probably a bit late for you, but I'll do some tests during the > afternoon and I'll prepare an email on how we could proceed. > > As already discussed my overall idea would be: > - integrate the Maven Bundle Plugin [1] in the build process: it is > really not intrusive and simply generates a MANIFEST based on the > compiled class (this generation can also be very finely configured) > - I expect this to work pretty well on the "pure" java modules > - then we can dig into the problems with all the imageio stuff, thread > context classloader etc. > > Until then have a nice weekend! > > Mathieu > > [1] http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html > ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
