Community
Participate
Working Groups
When you create a RAC plugin, you put it in a subdirectory of the "plugins" directory. The name of the subdirectory serves as the plugin's name. Due to the way plugins are packaged in the build, the directory names for the TPTP plugins now have a version number on them, so today we have org.eclipse.hyades.execution_4.0.0, for example. The trouble is, the whole directory name is used to identify the plugin in the "requires" attribute of the <PluginConfiguration> element. This creates a critical version-to-version compatibility issue: if my third-party plugin depends on a TPTP plugin and the user installs a hypothetical version 4.0.1, my dependent plugin won't work any more, no matter how API-compatible the new version is. One possible solution (if you want to keep the version numbers in the RAC plugin directory names) is to change the RAC's processing of the "requires" attribute. If the "id" for a plugin you depend on is just the part before the first underscore instead of the whole directory name, then installing a new version won't break the dependency chain.
This is a valid bug. The problem is that RAC config loader does not take into account the version numbers and tries to perform an exact match in the plugin name in the "requires" field inside pluginconfig.xml. That means plugin configs need to know the versions they are requiring when generating their cofig files... which is not good. My proposal is: 1) try to perform an exact match, and 2) if no hit, try to match without the version numnber (the "_4.0.0" part for example). If no hit afterall we declare the required plugin does not exist. If there is more than 1 version of the same plugin exist, which is not a supported scenario for the RAC, we will try to perform a match on the first one returned by the operating system if the "requires" does not supply a version number. Retarget to 4.0i4 per discussion with Hendra.
Adding documentation requirement.
Fixes checked into CVS 5/26/2005 14:00 EDT. Doc is to be added under bug 97920.
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
