> The same package in multiple modules is a classic OSGi problem called the > "split package" issue. The bnd tool provides some directives to mark > exported packages as split across multiple bundles leaving giving the > runtime classloader the chance resolve classes in these packages across > bundles.
Yes, but split-packages (even though in the specifications) are IMHO more a kind of workaround mostly required in the Eclipse context. In practice they should really be avoided, they add complexity and make some underlying issues in the module structure less visible. I tried to use them to work around the gt-epsg-hsql issue but it did not work right away, and I did not invest more time in this trail at this stage. But I fully agree with you that in the short-term we should use all what is available to workaround the problems. > Basically marking exported packages as split and merging them in client > bundles using require-bundle directive. This is pretty messy and hopefully > will not result in cyclic dependency issues. There has been a lot of discussion in the OSGi community around whether Require-Bundle directives should be used or not. Many people agree that Import-Package is best practice. See http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html But in an Eclipse context this is sometimes unavoidable or way easier: http://www.osgi.org/blog/2008/06/jsr-277-and-import-package.html (by Argeo, our policy is to use only Import-Package, esp. for low-level libraries, except in Eclipse RCP/RAP) Because this is an important point, that we would need to discuss anyhow, let me illustrate it, first with an example from our experience and then seeing how it could apply for GeoTools. We tend to use a lot of packages from the Spring Source Enterprise Bundle Repository: http://ebr.springsource.com They repackage third parties by naming them: com.springsource.<package root> e.g. com.springsource.org.apache.commons.io Sometimes we need to repackage some of these libraries, either because we need to update them and they haven't yet, or because some of their metadata do not fit our context (e.g. forcing the version of javax.* bundles in order to support Java 1.4, whereas we only support Java 1.5+). Our own repackaged bundles are named: org.argeo.dep.osgi.<library name> (for the record, but OT: will probably change soon) If our apps would use Require-Bundle, they would be broken when we perform such a change. With Import-Package, this is completely transparent. Now let's move to a popular free software library such as GeoTools, that you want to hack/fork/repackage etc. The nice thing with Import-Package is that your application just says, for example: "I want the capabilities provided by org.geotools.referencing". It may be provided by the "official": org.geotools.gt-referencing but also by: org.opengeo.org.geotools.referencing (because they wanted to quickly patch something for a customer) or by org.geonode.org.geotools.referencing (because they use a custom GeoServer) or by org.argeo.dep.osgi.geotools.referencing (because we tweaked the OSGi metadata so that it works well with our RCP/RAP application) or eu.udig.org.geotools.referencing (because they tweaked the OSGi metadata so that it works well with the existing code base) So, to sum up, I think that Import-package is "better" in general, but especially for free software base libraries. It unlocks a great strength of free software: you can hack, you can repackage. ------------------------------------------------------------------------------ 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
