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

Bug 329287

Summary: org.eclipse.core.runtime.compatibility.registry shows error for removed class
Product: [Eclipse Project] PDE Reporter: Thomas Watson <tjwatson>
Component: API ToolsAssignee: PDE API Tools Inbox <pde-apitools-inbox>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: curtis.windatt.public, Michael_Rennie, Olivier_Thomann, pwebster
Version: 3.6Flags: Michael_Rennie: review+
Target Milestone: 3.7 M4   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
First draft
none
Updated patch none

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.