Community
Participate
Working Groups
I20080805-0100. 1. started my workspace (which had no errors) using I20080805-0100. ==> all good 2. imported all unshared binary plug-ins from I20080805-0100. ==> tons of API tooling errors on interfaces: The super interfaces set has been reduced for type 'T' (T stands for the concrete type) plus: errors on many manifest files: The major version should be incremented in version 3.5.0.qualifier, since API breakage occurred since version 'v' (v differs from plug-in to plug-in) Similar errors were already reported but are marked as fixed (see bug 224969 and bug 233426).
Nothing in .log. I use R3.4 as API baseline. - cleaning the affected projects does not help - cleaning and rebuilding all does not help - restart does not help - restart + rebuild does not help - going back to R3.4 does not help There seems to be no way to fix this. Also, I tried to reproduce starting with a fresh workspace but no luck. There seems to be some api tooling data being cached that I can't get rid of. I now removed the API baseline (adding it back brings the errors back).
Basically this is a blocker for me, assuming that API tooling should be used for development. Is there any way to clear the cached data or to debug this issue?
(In reply to comment #2) > Basically this is a blocker for me, assuming that API tooling should be used > for development. Can you tell which (or some of which) projects have these errors in them? > > Is there any way to clear the cached data or to debug this issue? > You could try deleting the API description(s) data found here: workspace\.metadata\.plugins\org.eclipse.pde.api.tools\<project name> where <project name> is a folder for each project with an API description, with a .api_description file inside the folder
Can you tell which (or some of which) projects have these errors in them? For example org.eclipse.search and org.eclipse.jdt.ui. >You could try deleting the API description(s) data found here: Are there any possible bad side effects?
(In reply to comment #4) > Can you tell which (or some of which) projects have these errors in them? > For example org.eclipse.search and org.eclipse.jdt.ui. > > >You could try deleting the API description(s) data found here: > Are there any possible bad side effects? > If you shut down Eclipse, delete them and restart, it will just recreate them. The only bad side-effect is that the first build will take a bit longer.
Try as I might I cannot reproduce (on new and existing workspaces). I do however get a bunch of API usage errors on jdt.ui like: Type ChangeTypeRefactoring illegally instantiates GeneralizeTypeDescriptor are these expected problems?
>Type ChangeTypeRefactoring illegally instantiates GeneralizeTypeDescriptor >are these expected problems? Yes.
Deleting the meta data did not help.
The problem is that we are failing to find expected interfaces in the workspace profile while building the super interface set. Tracing from Daniel's workspace is filled with problems like the following: SUPERINTERFACES LOOKUP: Could not find interface org.eclipse.jface.wizard.IWizard in profile workspace from component org.eclipse.team.ui Which causes the number of interfaces in the workspace set and baseline set to differ, leading to the "Reduced super-interfaces..." problems. Not sure yet why the workspace profile lookup is failing.
>Not sure yet why the workspace profile lookup is failing. Maybe outdated JDT Core cache info? I suggest we start my workspace in Debug mode and then step through the relevant code together.
Why are error markers created if there isn't even enough information to compute it correctly (see comment 9)? Shouldn't the API tooling rather do nothing than add false positives? OK, I found the problem: Compare recently split org.eclipse.compare into org.eclipse.compare.core and org.eclipse.compare (UI part). Now, when moving forward to the new I-build I imported all existing non-shared plug-ins and hence missed to import org.eclipse.compare.core. Since none of my source plug-ins use compare core code there are no errors reported anywhere about this missing plug-in. PDE API tooling however seems to get confused about this. Test Case: 0. install I20080805-1307 1. start fresh workspace 2. on PDE 'Target Platform' pref page disable all plug-ins 3. add a CVS connection to dev.eclipse.org:/cvsroot/eclipse 4. select and then check out the following items in the 'CVS Repositories' view: - 'org.eclipse.ltk.ui' project - 'org.eclipse.team.ui' project - 'platform-text' MODULE 5. import all required plug-ins as binary EXCEPT org.eclipse.compare.core ==> so far no errors 6. now define 3.4 as API baseline ==> tons of errors If the API tooling has problems with such a setup then it should generate an error (e.g. on org.eclipse.compare) and stop analyzing the code and generating false error markers.
Easily reproducible from the steps given in comment 11. Related to the improper handling of re-exported bundles (bug 240914). We definitely need to fix our comparator to not report false positives in the face of missing information.
Created attachment 109343 [details] proposed fix for comparator This proposed fix for the class file comparator introduces a status to the comparator to allow it to log status as it is processing. The status is then used during processing to ignore certain tests that depended on the OK status of the comparator, allowing us to skip creating some false positive deltas (like those described in this bug). The use of the status also allows the comparator to continue processing in the face of problems, for those comparisons that do not depend on the OK status of the comparator. The status of the comparator can be requested via the getStatus() method. This patch does not address the re-exported bundles issue.
Note that if PDE would also flag missing required bundles in binary projects I would have detected this much earlier. Any reason why this isn't done?
(In reply to comment #14) > Note that if PDE would also flag missing required bundles in binary projects I > would have detected this much earlier. Any reason why this isn't done? > I can't say why they don't, cc'ing Chris and Curtis for comment.
Lowering severity as there is a known cure: 1. create a new 'Eclipse Application' 2. switch to the 'Plug-ins' tab 3. hit 'Validate Plug-ins' 4. add the missing required plug-in(s)
Applied patch Now no false positives are reported and any bad status from the comparator is reported in the error log.
Marking fixed. This bug was due to a profile that had resolution errors. Now we no longer report false positives in this case.
Verified.