Hi Mathieu: I am going to have some time this week to go over your ideas and turn them into a proposal. Are you set up for editing on the wiki? We had some trouble with Jira being broken into and a lot of the passwords have been reset; so even if you had access before you should check.
Jody On 01/06/2010, at 7:33 PM, Mathieu Baudier wrote: > 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 <mbaud...@argeo.org> 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 >> ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
