Add ability to check for dso version in config modules.

Type: New Feature
Status: Closed
Priority: 2 Major
Resolution: Fixed
Component/s: DSO:L1
Labels:

Assignee: drb
Reporter: steve
Created: March 12, 2007
Votes: 0
Watchers: 0
Updated:
July 27, 2012
Resolved:
March 13, 2008

Description

When someone writes a config module it might rely on certain features of a given version of the dso platform. We should be able to check against that version.

Comments

Nathaniel Harward 2007-04-14

I think we should align the value of the “Bundle-Version” MANIFEST.MF header in “modules-common” to the DSO release version, so in trunk it should be 2.4.0.

Juris Galang 2007-05-01

This is a bit funky. We should be able to mix and match bundle versions with TC versions… Let’s flesh it out some more.

Nathaniel Harward 2007-05-02

I respectfully retract my comment above about matching the modules-common version with the system release version. Perhaps we should have the following class (or something like it) in modules-common instead, which modules can interrogate (in addition to specifying version dependencies on modules-common itself):

package org.terracotta.modules;

public final class DsoSystem {

public static String getVersionString() {
    // Read a build-system-generated resource with this value, hard code it, whatever...
    return "....";
}

}

That way if I have a dependent module that works with releases 2.3, 2.4 and 2.5 but not 2.6 (say versions 1.0.0, 1.1.0 and 2.0.0 of modules-common respectively), but does something special for 2.4 I can do something like this:

META-INF/MANIFEST.MF: Import-Package: org.terracotta.modules.DsoSystem;version=”[1.0.0, 2.0.0)”

Config module code: // At this point we know we are in the 2.3 - 2.5 release version because of the import statement in MANIFEST.MF …. if (DsoSystem.getVersionString().matches(“^2.4.*$”)) { // Do something special for 2.4…. }

Just thinking/writing out loud here – any opinions or suggestions?

Nathaniel Harward 2007-05-02

A few corrections to my “code” above:

META-INF/MANIFEST.MF (should not have included specific class, only package): Import-Package: org.terracotta.modules;version=”[1.0.0, 2.0.0)”

Config module code: …. import org.terracotta.modules.DsoSystem; …. ….rest of example above….

Steve Harris 2007-05-02

I can never make up my mind about what I think is best in this situation? “Simplicity” by just returning a version string and leaving the logic in the app. or “Simplicity” by having the app pass the current version into a method in the module and let it return whether it is compatible. decisions decisions

Nathaniel Harward 2007-05-02

The problem with passing the version into a method in the module is that you still have the same versioning dependencies problem – the module has to implement some interface we create and would package up as part of modules-common. Also, the app still has to perform logic in the code, it would just be in a forced interface method (which might be awkward) rather than an external method call. It seems to me that since this is a style issue not in our code but in the config modules, that rather than complicate our code to look for some interface in some unspecified set of classes in every module (and force a potentially awkward interface on all module writers), the module can just ask for the version if it needs to do something special.

Ideally this would never happen anyway and the whole thing could be taken care of with the Import-Package (+version) property in MANIFEST.MF, but if you have the odd case like I described above you could resort to coding around something by calling DsoSystem.getVersionString() (or whatever it will be).

Juris Galang 2008-03-13

CDV-636: TC Version Check of TIM CDV-167: Add ability to check for dso version in config modules. DEV-1128: TIMs need manifest attribute specifying supported Terracotta version

Code and tests to check for required TC version for TIM’s. A new attribute named Terracotta-RequireVersion is added into the manifest of all TIM’s that comes packaged with the kit. When TC installs a TIM at runtime, this attribute’s vvalue is compared against TC’s version number and appropriate action is taken (see CDV-636 for details)