> I am going to try and turn your email into a proposal as I understand it. The > proposal will need to have a couple of examples in it to explain to PMC > members what it is we are planning to do. I was not aware of the progress > made by the spring source maven repo - interesting.
examples => I'll be happy to provide you with examples of ideas we have. Basically, I would like to be able to integrate GeoTools in the same kind of standard (that is, non-GIS) middleware we use, which are based on combining Spring dependency injection and OSGi services (more on this when needed) Spring Source repo => this is indeed a very important development, and actually what triggered our switch to a full-OSGi approach two years ago: previous attempts had stumble on packaging as OSGi bundles the many FLOSS dependencies we use. However it happens fairly often that we need to repackage some bundles ourselves (typically to put some package dependencies as optional or do some low-level OSGi trickery). This is not complicated at all thanks to the Maven Bundle Plugin => as soon as you have the original jar in a Maven repo you can just enrich the OSGi metadata. > I would like to ask what it takes to publish to the swing source maven repo; > we have another outstanding request to publish to a more central repository. I guess you meant "Spring Source". You can fill a JIRA entry to require new packages to be added. To be frank I'd be careful with this approach: Spring Source have their own interests and priorities and this Maven repository is not really meant to be a community effort. My understanding is that they needed to repackage all this stuff anyhow for their customers, so why not share it and have other people testing it. This makes sense and is much appreciated (see above), but I tend to be careful with it and stay flexible (just as we use CentOS and EPEL but also maintain our own RPMs when needed) > For modules that we are unable to produce a MANIFEST.MF for at this time we > will need to leave them in the build, they just would not end up with a > MANIFEST.MF until their requirements can be met. Just to be precise, we can already generate a MANIFEST for all modules (see my previous mail). The question will be whether this MANIFEST will be usable. Anyhow, I see your point, and I think this is not a big deal and that the goal is first to have the "core" features available. > We will have to at the end of the day produce a patch to apply to geotools > trunk; should be break of a temporary branch to do the work in the iterative > fashion you suggest? It depends whether: - the project structure and the POMs often change (the java code is not important) => a separate branch will be harder to merge if the trunk POMs often change because there will be conflicts (we will mostly impact the POMs) - I have some kind of write access on the branch => this would be an argument for the branch since we will be able to work faster if you don't have to apply my patches each time As I said, I am equally comfortable with setting up a project in our own infrastructure, which would take the GeoTools trunk as an input. In the end, we will probably use our own repackage of the GeoTools jar, be it only to have a consistent naming of the jars: by convention OSGi jars are named after their symbolic names (which raises again the question of the symbolic name, see my previous mail) > > 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 <[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
