Page History

...

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 MarkupFigure 4) and Figure 5) are showing the two extremes, the version range we want may be somewhere in between. eg. By using the version range \ [1.2.5,2.0.0) of Axiom, Tuscany will be importing any version of Axiom within this major version 1, and preventing importing of the next major version 2, which may contain breaking changes.

If you have actually read this far, you must be patient. I will try to summarize now.

...

1. 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.
2. All Tuscany modules export packages at Tuscany version (eg. 1.4.0), all third party libs export packages at their jar version.
3. All bundles with exports will also import those packages using the same version range as other importers  (OSGi best practice)
4. Imports and "uses" statements in exports
   1. Minimum version: same as currently used version in Tuscany
   2. Maximum version - use defaults in the first instance for all 3rd party libs (ie. maximum version is infinity).
   3. Wiki MarkupMove to maximum version under current major version, Eg. Jaxb 2.1.6 will be imported using version range \ [2.1.6,3.0.0)
   4. Fine tune further to narrow down version ranges for specific third party libs as we learn more.

...