• Bug
  • Status: Closed
  • 0 Showstopper
  • Resolution: Fixed
  • teck
  • Reporter: teck
  • July 08, 2010
  • 0
  • Watchers: 1
  • November 09, 2010
  • July 20, 2010


When we move from toolkit API 1.0 to 1.1 we’ll currently need to rebuild many things. The reason is that the API version is contained in the artifactId of the toolkit artifact. That name also ends up in the Require-Bundle header for TIMs (eg. tim-ehcache, tim-quartz, etc) that depend on the toolkit. The OSGi runtime isn’t going to let those things load since there will be no such bundle present.

One idea is to dynamically change MANIFEST.MF as it is being loaded to match the “correct” version of the toolkit.

So lets say a TIM jar is being loaded into an L1 that references toolkit-1.2. But your terracotta-toolkit-runtime actually has version 1.7 lets say. In that case we fix the MANIFEST to require version 1.7. The rule for toolkit API versions is that moving forward with minor revisions should always be safe. You can never cross major versions and you can’t ever go backwards (ie. 1.0 is not compatible with 1.1)


Tim Eck 2010-07-20

I think this should be working now. The module resolver in core 3.3.1+ is aware of the toolkit and it’s versioning rules now. As modules are loaded it will find if there is a violation of major toolkit version numbers and will locate the maximum required toolkit API.

For express usage the toolkit API is specified explicitly and all modules loaded must use API versions equal to (or less than) then the one in the toolkit runtime

Fiona OShea 2010-08-24

Tim is this Magnum (3.4) related as it is the next actual release we do or was it specifically 3.3 branch related?