THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
In this case, apart from Tuscany SPI/SCA API, which are exportingwe want others to use, other import/exports will look like:
...
How complicated can it be? We have version numbers across all jars and bundles and we want to put sufficient restrictions in place to use appropriate versions of jars. For small applications, versioning is not a big deal, and can be easily handled using defaults from tools. But for something the size of Tuscany with nearly 150 third party libraries which is used to assemble applications which may use some of these jars for other purposes, import versioning can indeed be extremely complex to support all possible scenarios. The level of sharing of classes required, the level of isolation required for side-by-side execution of multiple versions, the flexibility required for upgrading 3rd party libs and the actual version ranges that are compatible should all be taken into account to determine the optimum version range (for each of the 150 3rd party libs).
Let us start with a (simple) scenario:
...
This is the default used by most tools like maven-bundle-plugin, and other versions of 3rd party libraries from repositories like SpringSource also make version ranges in imports as broad as possible. OSGi spec says: "the import should be as unconstrained as possible to allow the resolver maximum flexibility". So what does this really mean?
...
The broader the version range, the higher the class sharing that is enabled. Since we still have 3rd party libraries which rely on thread context classloaders which dont fit in with OSGi modularity/versioning, a broad range in import versioning reduces the risk of classloading errors arising from multiple definitions of a class in different classloaders.
But there is a negative side - as shown in Figure 4, we are preventing side-by-side execution of different versions of jaxb.
Another scenario is upgrading one 3rd party library in Tuscany. An user wants to migrate Tuscany to using version 1.4 of Axiom. A flexible versioning system enables the user to just install the new version of Axiom, without any changes to Tuscany bundles. eg. An user can get Axiom 1.4 from SpringSource and easily run it with Tuscany without waiting for the next release of Tuscany that ships with Axiom 1.4.
But there is a negative side - as shown in Figure 4, we are preventing side-by-side execution of different versions of jaxb. Also we cannot easily prevent Tuscany being run with a newer version which may be incompatible if an application wants to switch to a newer version.
Narrow version ranges in imports
...
So narrow version ranges can reduce class sharing and increase side-by-side execution, but that also make upgrades difficult, introduces more number of classes loaded in the system, and can result in classloading exceptions resulting from multiple definitions of classes. TCCL based classloading can potentially lead to exceptions.
Wiki Markup
If you have actually read this far, you must be patient. I will try to summarize the points that we need to considernow.
Points to consider for versioning 3rd party libs
...
- One bundle per Tuscany module, one bundle per 3rd party lib
- Based on the discussion on aggregating modules into larger bundles, Tuscany module bundling may change.
- All Tuscany modules export packages at Tuscany version (eg. 1.4.0), all third party libs export packages at their jar version.
- All bundles with exports will also import those packages using the same version range as other importers (OSGi best practice)
- Imports and "uses" statements in exports
- Minimum version: same as currently used version in Tuscany
- Maximum version - use defaults in the first instance for all 3rd party libs (ie. maximum version is infinity).unmigrated-wiki-markup
- Move to maximum version under current major version, Eg. Jaxb 2.1.6 will be imported using version range \ [2.1.6,3.0.0)
- Fine tune further to narrow down version ranges for specific third party libs as we learn more.
...