> The package of interest that is split for me in Geotools is > org.geotools.data between main and api. There would be issues with > org.geotools.util as well down the track. There are similar issues with > NetCDF. I will attempt the package fusion as you suggested. I will start > with my netcdf gunk first since I only need to fuse 2 jars.
Yes, in the long run, we probably all want to have the GeoTool bundles in line with the GeoTools modules, but until it is possible, nothing technical forces us to do so. An OSGi bundle is nothing more than a collection of packages + the definition of their visibility at the component level. So it is completely up to the packager which packages are in a given bundle. (cf. my examples of how various projects may want to have different bundles) This is another pragmatic alternative to the issues we will face in the short-term, that I would tend to support more than split-package / Require-Bundle (see my previous post). If you want, I can quickly set up an artifact in the branch, which would provid a merged gt-main and gt-api (I would like such artifact deifnitions to be isolated and defined under osgisandbox/merged). You could then reuse this pattern for other modules if needed. Feel free to look at: https://svn.argeo.org/dependencies/trunk/org.argeo.dep.osgi/ where we create OSGi bundles based on regular Maven jar artifacts, with for example: https://svn.argeo.org/dependencies/trunk/org.argeo.dep.osgi/geotools/pom.xml (we also merge the sources, because open source without sources is a bit sad). These POMs mostly use standard Maven plugins, except for merging the services files, where we use our own OSGi plugin (but the services files can be merged and added manually if you don't want to depend on it). > I have been testing the plugin branch. With regards to the services, I have only been testing on gt-referencing, so please let us know if you encounter issues higher up the stack. We may need to slightly tweak the metadata generation for some modules, just as I did for gt-metadata and gt-referencing. Please also note that the automated Eclipse PDE target platform generation under osgi/sandbox/dep/* also repackage source files as source bundles that the PDE automatically attaches to the dependencies. This is very useful when developing. Please let me know if I can help you more with setting up your development environment. If you want a target platform with more dependencies, just copy osgisandbox/dep/org.geotools.osgisandbox.dep.referencing into, say: osgisandbox/dep/org.geotools.osgisandbox.dep.netcdf and this artifact will generate the appropriate target platform as well (these generated target platforms point to the jars in your local Maven repo under .m2/repository, so you can create as many target platforms as you want and it won't increase the size used on your disk). Hope it helps. Good luck! Mathieu ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
