Page History

...

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

...

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

...