Bug 329287 - org.eclipse.core.runtime.compatibility.registry shows error for removed class
Summary: org.eclipse.core.runtime.compatibility.registry shows error for removed class
Status: VERIFIED FIXED
Alias: None
Product: PDE
Classification: Eclipse Project
Component: API Tools (show other bugs)
Version: 3.6   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.7 M4   Edit
Assignee: PDE API Tools Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-02 14:33 EDT by Thomas Watson CLA
Modified: 2010-12-08 15:54 EST (History)
4 users (show)

See Also:
Michael_Rennie: review+

Attachments
First draft (4.12 KB, patch)
2010-11-02 15:06 EDT, Olivier Thomann CLA 		no flags Details | Diff
Updated patch (5.99 KB, patch)
2010-11-02 15:27 EDT, Olivier Thomann CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA 2010-11-02 14:33:50 EDT 
I released the patch in bug329277 to head.  But now if you have org.eclipse.core.runtime.compatibility.registry checked out from head and are using a 3.6.x API baseline you get an API error saying

The type org.eclipse.core.runtime.IPluginDescriptor has been removed from org.eclipse.core.runtime.compatibility.registry_3.3.100	MANIFEST.MF	/org.eclipse.core.runtime.compatibility.registry/META-INF	line 1	Compatibility Problem
Comment 1 Olivier Thomann CLA 2010-11-02 14:44:00 EDT 
The problem is that the source path entry for "classes" has been removed. In the pde api tooling code, we used to "parse" the "source." entries for a specify jar entry and this is how we got the .class file located inside the "classes" folder.
So we need a new way to be able to retrieve the class inside that class folder.

"classes" is really a class folder, so it should not be part of the source folders.

I wonder if we should not include the "extra." classpath entries as part of the api component containers. If this jars are required at compile time, there is a good chance that they are also required at runtime to "resolve" signatures.
Comment 2 Olivier Thomann CLA 2010-11-02 15:06:31 EDT 
Created attachment 182235 [details]
First draft
Comment 3 Olivier Thomann CLA 2010-11-02 15:27:05 EDT 
Since we are potentially using the contents of the build.properties file to initialize the api type containers, we should also listen to changes made in that file.
Comment 4 Olivier Thomann CLA 2010-11-02 15:27:48 EDT 
Created attachment 182240 [details]
Updated patch

Same patch with rebuild made when build.properties file contents has changed.
Comment 5 Olivier Thomann CLA 2010-11-03 13:12:15 EDT 
This patch passes all API tooling tests.
Comment 6 Michael Rennie CLA 2010-11-05 10:38:22 EDT 
+1 looks good, all smoke / unit tests pass.

I applied the patch to HEAD.
Comment 7 Curtis Windatt CLA 2010-12-08 15:54:08 EST 
Olivier and Mike both reviewed the changes.  Removing Darin as reviewer and marking as VERIFIED.