Bugzilla – Full Text Bug Listing
| Summary: | Wrong error reported + error in .log | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Dani Megert <daniel_megert> | ||||
| Component: | UI | Assignee: | PDE-UI-Inbox <pde-ui-inbox> | ||||
| Status: | CLOSED DUPLICATE | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | darin.eclipse, deepakazad, markus.kell.r, Michael_Rennie, Olivier_Thomann, pwebster | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Dani Megert
Created attachment 159458 [details]
Team Project Set
Reproduced. The project org.eclipse.ui.editors is not built yet when the type org.eclipse.ui.texteditor.DefaultMarkerAnnotationAccess is retrieved. Therefore it cannot be found and the method is reported as not found.
The method is retrieved during api usage check of the bundle org.eclipse.ltk.ui.refactoring.
org.eclipse.ui.editors is retrieved as one of the prerequesite of
org.eclipse.ltk.ui.refactoring.
See org.eclipse.pde.api.tools.internal.builder.ReferenceAnalyzer.buildProblemDetectors(IApiComponent, int, IProgressMonitor):
IApiComponent[] components = component.getBaseline().getPrerequisiteComponents(new IApiComponent[]{component});
The problem with the error being reported seems to come from the fact that the api description from the project in the workspace is inconsistent. The method handle org.eclipse.ui.texteditor.DefaultMarkerAnnotationAccess#org/eclipse/ui/internal/texteditor/AnnotationTypeHierarchy getAnnotationTypeHierarchy() is not found in the API description.
Its parent node is returned and it doesn't have any restrictions.
Type Node: org.eclipse.ui.texteditor.DefaultMarkerAnnotationAccess
Visibility: INHERITED
Restrictions: NO_RESTRICTIONS
Parent: org.eclipse.ui.texteditor
This is why the method is reported as being added and therefore the @since tag is inconsistent.
I need to investigate why the annotation description is out of date.
Once I exit the api description is properly written on disk and contains the following entry:
<type handle="=org.eclipse.ui.editors/src<org.eclipse.ui.texteditor{DefaultMarkerAnnotationAccess.java[DefaultMarkerAnnotationAccess" modificationStamp="4" restrictions="0" visibility="0">
<method name="getAnnotationTypeHierarchy" restrictions="8" signature="()QAnnotationTypeHierarchy;" visibility="0"/>
</type>
About the fact that org.eclipse.ui.editors is not built when building org.eclipse.ltk.ui.refactoring, I think the problem comes from the build order in the workspace. When you have these projects in your workspace: org.eclipse.ltk.core.refactoring org.eclipse.ltk.ui.refactoring org.eclipse.ui.editors org.eclipse.ui.workbench.texteditor The default build order is: org.eclipse.ltk.core.refactoring org.eclipse.ltk.ui.refactoring org.eclipse.ui.workbench.texteditor org.eclipse.ui.editors If you check out org.eclipse.compare inside the workspace, the default build order becomes: The default build order is: org.eclipse.ltk.core.refactoring org.eclipse.ui.workbench.texteditor org.eclipse.ui.editors org.eclipse.compare org.eclipse.ltk.ui.refactoring So the first build order looks boggus. It should be: org.eclipse.ltk.core.refactoring org.eclipse.ui.workbench.texteditor org.eclipse.ui.editors org.eclipse.ltk.ui.refactoring If I force that build order, the original problem is gone. So I open bug 305732 to track down the build ordering issue. Meanwhile the only way to fix this is to manually change the build order by going to: Window>Preferences>General>Workspace>Build Order. Uncheck "Use default build order" and move org.eclipse.ltk.ui.refactoring to the bottom. > Meanwhile the only
>way to fix this is to manually change the build order by going to:
>Window>Preferences>General>Workspace>Build Order.
This is not a real option since though it "works" for the given test case: I might have much more (or different set of) projects and API tooling failing on me without having a clue why. No one would come to the conclusion that he has to define the build order manually.
(In reply to comment #6) > This is not a real option since though it "works" for the given test case: I > might have much more (or different set of) projects and API tooling failing on > me without having a clue why. No one would come to the conclusion that he has > to define the build order manually. API Tooling made the assumption that dependent projects are built by the time a project is being built. If this is not true anymore, then we need to revisit that code. I still believe that the build order is not properly computed in this case. *** Bug 302000 has been marked as a duplicate of this bug. *** I don't see how this can be fixed from the API tooling side when we only rely on dependents being compiled first. This should be a valid assumption. The fix should come from PDE that should set the dynamic order for building the projects in the "right" order. Moving to PDE/UI to investigate how the dynamic order can be set. This problem/solution is better described in bug 305732. This is a fairly complex enhancement to make at this point in 3.6, so I propose to defer. (It's not a regression either). *** This bug has been marked as a duplicate of bug 305732 *** |