Hi Mathieu, I will test along with your work. I have successfully osgified NetCDF maven builds with the same snippet you used for Geotools. I wanted a quick fix without actually resolving package dependencies for all parts of the code which Bnd auto-calculates. So I applied the following hack in the maven plugin config to produce minimalistic metadata which makes the bundles fail-at-end possibly during integration testing.
https://issues.apache.org/jira/browse/FELIX-954 I approve of your approach in principle. The JBoss life-cycle interception technique is a source of inspiration rather than a must use implementation. Feel free to do it some other way. Regards, Tisham. > Hello Jody, Tisham, > > I have made my first commit into the plugin branch (r37162), by > integrating the generation of the OSGi metada in the MANIFESTs using > the Felix Maven Bundle plugin. > > This is basically the patch that I had sent recently and that Tisham had > tested. > > I plan to work as follow, please tell me if you agree with the > approach before I make further commits: > > - I will create a (temporary) /osgi directory at the root of the > branch, which will be our playing ground. > The rationale for a dedicated directory is that we will probably need > quite a few bundles (=> directories / eclipse projects) in order to > implement and test the various approaches. > > - in order to move on quickly, I will use tools that my organization > has developed in order to generate PDE target platforms using Maven > etc (all Apache 2 licensed). This will allow anybody to quickly set up > projects compatible with the Plugin (<=> OSGi) Development Environment > (PDE) in Eclipse. > No need to say that using these tools won't be a requirement for the > approach that we will use in the end. > > - I will also use third-party libraries that we had already packaged > as OSGi bundles (e.g. jts, java3d, jsr275, etc.) and which are > available in our public Maven repo. I had packaged these libraries > using the Maven Bundle plugin and the original GeoTools dependencies, > so it should be easy to reuse them for the final approach > > Anyhow, the idea is to have ASAP something to test our various ideas, > that can easily be reproduced by others than me. > > I will first start with the publication of the services/* > implementations at runtime (point 1 of Tisham previous mail). I am not > sure that I want to reuse the JBoss stuff though. This is not that > complicated to do and JBoss utilities as dependencies are often > painful according to my (perhaps outdated) experience. > > When this is done, that will be a first milestone for us all to test > and discuss, before maybe going to the other approach (generation at > compile time, Tisham's point 2). > > I will test on the simple yet illustrative use case of the CRS > factories as suggested by Jody long ago, and I will probably reuse > some stuff I had already tried on my side over the last few months. > > All comments, critics, alternative ideas more than welcome. > > Cheers, > > Mathieu > ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
