> Is the proposal going to ask that every module maintainer picks > the dependencies only from the Spring repos, or otherwise dependencies > that have the proper OSGI meta-files? What if we need a dependency > that is not there, must we go and repack it with the proper informations > and upload to the OSGEO repository?
You're perfectly right to be worried about this, because maintaining third party dependencies is a big part of the work when using OSGi. Fortunately, OSGi imposes constraints only when you run it in an OSGi runtime. Otherwise an OSGi instrumented jar is only a jar and it works perfectly fine with regular (non-OSGi) jars. Last month we have repackaged some core modules of GeoTools (and some of their dependencies) as OSGi bundles that we simply run with our own set of third party dependencies (all OSGified), that we call our "distribution" (by similarity with the Linux distributions). Here is an example of v1.0.3 of this distribution (GeoTools + deps are targeted for the soon to be released v1.0.4): http://www.argeo.org/projects/distribution/site/1.0.3/versions-all/dependency-management.html You can see that some come from SpringSource, some were repackaged by us etc. So we can imagine to keep the current set of dependencies unchanged, and propose a separate set of deps for those willing to ruin an OSGi runtime. I'm pretty sure that Eclipse RCP developers would have other requirements in terms of third-party OSGi bundles, than thos of server-side/Spring based OSGi developers like us. The keyword is flexibility, I would say. ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
