Hello, Are there guidelines that would be useful in defining version constraints when OSGi-enabling 3rd party libraries? Typically, should constraints be made as broad as possible to enable flexible resolution, or should they be made as narrow as possible to enable multiple versions to coexist? The OSGi specification says "the import should be as unconstrained as possible to allow the resolver maximum flexibility" in the context of importing exported packages. But doesn't too unconstrained also mean that multiple variants cannot execute side-by-side?
To add some context to the question, we are looking at OSGi-enabling Tuscany which uses around 150 3rd party libraries. Many of these libraries are likely to be shared with applications, and in some cases, applications may want to use a different version of a library and share it with Tuscany, and in some other cases applications may want to use a different version of a 3rd party library from Tuscany without any sharing. Is there a recommended versioning technique which would do the right thing in a vast majority of cases? Is there any way that we can completely avoid applications ever having to uninstall Tuscany's version of 3rd party bundles, regardless of what sharing/isolation they require? Thank you... Regards, Rajini
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
