Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 95241

Summary:	(Plat) RAC plugin system has version number dependency in "requires"
Product:	z_Archived	Reporter:	Allan Pratt <apratt>
Component:	TPTP	Assignee:	Samson Wai <samwai>
Status:	CLOSED FIXED	QA Contact:
Severity:	critical
Priority:	P1	CC:	kcoleman, smith
Version:	unspecified	Keywords:	Documentation
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	closed460
Bug Depends on:
Bug Blocks:	97935

Description Allan Pratt

2005-05-13 19:21:45 EDT

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.

Comment 1 Samson Wai

2005-05-16 13:26:12 EDT

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.

Comment 2 Samson Wai

2005-05-26 14:01:32 EDT

Adding documentation requirement.

Comment 3 Samson Wai

2005-06-01 13:22:36 EDT

Fixes checked into CVS 5/26/2005 14:00 EDT.

Doc is to be added under bug 97920.

Comment 4 Paul Slauenwhite

2009-06-30 07:52:25 EDT

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.