Community
Participate
Working Groups
Created attachment 272850 [details] patch used to recreate this bug 1) Use debug code attached in the bug 2) Run API tools analysis ( keep relevant baseline - use default options) Lots of exceptions like below come with any API tool analysis !ENTRY org.eclipse.pde.api.tools 4 120 2018-02-22 16:17:13.780 !MESSAGE Error logged from API Tools Core: !STACK 1 org.eclipse.core.runtime.CoreException: Unable to resolve superclass org.eclipse.jface.dialogs.Dialog for org.eclipse.jdt.debug.ui.JavaSourceLookupDialog at org.eclipse.pde.api.tools.internal.model.ApiType.getSuperclass(ApiType.java:276) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.collectAllInterfaces(ClassFileComparator.java:771) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getInterfacesSet(ClassFileComparator.java:1891) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.checkSuperInterfaces(ClassFileComparator.java:272) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getDelta(ClassFileComparator.java:1023) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator$2.visit(ApiComparator.java:771) at org.eclipse.pde.api.tools.internal.model.ArchiveApiTypeContainer.accept(ArchiveApiTypeContainer.java:201) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.internalCompare(ApiComparator.java:656) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare(ApiComparator.java:286) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare(ApiComparator.java:312) at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.checkCompatibility(BaseApiAnalyzer.java:1442) at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.analyzeComponent(BaseApiAnalyzer.java:255) at org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.buildAll(ApiAnalysisBuilder.java:757) at org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.build(ApiAnalysisBuilder.java:361)
Bulk move out of 4.8 target milestone.
This needs to be looked at. Could also be a performance issue.
(In reply to Dani Megert from comment #2) > This needs to be looked at. Could also be a performance issue. See also bug 533091.
New Gerrit change created: https://git.eclipse.org/r/121896
Gerrit change https://git.eclipse.org/r/121896 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=79d2e597fe3e6fbff3642e8aaf5a4b16f52bb26d
I am unable to recreate this in Build id: I20180425-1705. I have committed the error logging code. Dani, can you please check if you still see these exceptions in the "Error Log" view on I20180427-2000 or later.
I am able to get org.eclipse.core.runtime.CoreException: Unable to resolve superclass org.eclipse.core.commands.AbstractHandler for test67.handlers.SampleHandler at org.eclipse.pde.api.tools.internal.model.ApiType.getSuperclass(ApiType.java:275) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.collectAllInterfaces(ClassFileComparator.java:774) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getInterfacesSet(ClassFileComparator.java:1894) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.checkSuperInterfaces(ClassFileComparator.java:272) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getDelta(ClassFileComparator.java:1026 on Build id: I20180427-2000 after I put in the error logging code. I will investigate this.
It recreates with Java 1.8 as well as Java 10. Simplest steps to recreate this 1) Create a plugin project with at least 1 api 2) Export and set the same as baseline 3) Clean-> Build All
New Gerrit change created: https://git.eclipse.org/r/121912
Gerrit change https://git.eclipse.org/r/121912 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=ed553025f248387ed5cfe8065dd7f2a82634b5ec
(In reply to Vikas Chandra from comment #8) > It recreates with Java 1.8 as well as Java 10. > > Simplest steps to recreate this > > 1) Create a plugin project with at least 1 api > 2) Export and set the same as baseline > 3) Clean-> Build All So, what's the conclusion?
>So, what's the conclusion? yet to investigate, Dani ! Since I was able to recreate it , I disabled the logging since the I build will have too many logging of "Unable to resolve".
(In reply to Vikas Chandra from comment #12) > >So, what's the conclusion? > > yet to investigate, Dani ! > > Since I was able to recreate it , I disabled the logging since the I build > will have too many logging of "Unable to resolve". That's good. I suggest you check whether this is a regression compared to 4.7. If not, I'm fine moving to 4.9.
Created attachment 273880 [details] Added debug code for logging and in launch version, I get this error. So this is not a regression.
However CoreException: Unable to resolve superclass" can be outputted from different locations and there could be multiple issues at hand. With comment#8, I have found 1 variation of this problem. Comment#0 could be same or different. Also bug 533091 could be because of same reason as comment#8 or different. I will update my findings regarding comment#8
>>I will update my findings regarding comment#8 Finally, I got around investigating comment#8. The reason for this particular problem was that there was a plugin test - lets say PluginA, in baseline which uses eclipse APIs. In the the workspace we have the same plugin Plugin A as source. During API analysis, API tools tries to fetch API classes of eclipse used in PluginA from the API baseline which just has PluginA ( + the system library). API tools is unable to get those eclipse API from the baseline and hence outputs this problem. Keeping a baseline which has eclipse plugins+PluginA solves this problem. Apart from the "Unable to resolve", other symptom of this will be API tool related analysis will be not reported for cases involving eclipse API. Keeping all the components involved in API analysis should be kept in baseline for proper analysis. This behavior is same since long and can be considered as work as designed. I do actually have a bad workaround ( see next comment) wherein I look for those APIs in workspace baseline and that solves this particular problem ( but I don't recommend this). May be adding dependent components in baseline can be an option ( but I don't recommend putting that either especially in RC2 since that would be design change and can have unexpected repercussion). A mid-way approach could be just giving a better message to the user that "eclipse.API is not found in the API baseline. Consider adding a baseline that contains eclipse.API as well" All said and done, this is the investigation for scenario of comment#8 and other scenarios may or may not be similar and may require separate investigation.
Created attachment 274114 [details] Just temporary code to back up my last comment
(In reply to Vikas Chandra from comment #16) > A mid-way approach could be just giving a better message to the user that > "eclipse.API is not found in the API baseline. Consider adding a baseline > that contains eclipse.API as well" I think currently we don't report an error anyway. Suggest to move to 4.9.
>> we don't report an error anyway. Yes, this exception is muted.
New Gerrit change created: https://git.eclipse.org/r/132282
Gerrit change https://git.eclipse.org/r/132282 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=046df7e2d790cda4537d0870d283418bf636cc2d
I believe there are at least 2 variations to this comment#7 Explained in comment#16 and comment#17 . Not a regression and probably nothing needs to be done here. comment#0 I am unable to recreate this and this looks more problematic ( since all dependent plugins are there in baseline). I have put the logging code so see if I can reproduce in the next I build on-wards.
(In reply to Eclipse Genie from comment #21) > Gerrit change https://git.eclipse.org/r/132282 was merged to [master]. > Commit: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?id=046df7e2d790cda4537d0870d283418bf636cc2d Vikas, I have 1216 errors reported by this patch on a full build of the workspace and my log overflows (3.7 MB now), so I had to increase log size. If we want this, we should have it a tracing option, disabled by default.
Created attachment 276580 [details] log file with gazillions of API errors
New Gerrit change created: https://git.eclipse.org/r/132458
Gerrit change https://git.eclipse.org/r/132458 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=538c31d5f95632fbd0211407b503739ba90b8553
>>Vikas, I have 1216 errors reported by this patch on a full build of the work Exactly what I wanted ! Can you please give a list of plugins in your workspace ( with exact baseline you are using)?
Meanwhile I will try to load as many repos as possible and try it myself.
Created attachment 276586 [details] Repos used I used all plugins in repos attached and still couldnt get this in error log in Version: 2018-12 (4.10) Build id: I20181114-1345 Andrey, any tips to recreate this on build I20181114-1345?
Created attachment 276594 [details] extra bundles in my SDK (In reply to Vikas Chandra from comment #29) > Created attachment 276586 [details] > Repos used > > I used all plugins in repos attached and still couldnt get this in error log > in > Version: 2018-12 (4.10) > Build id: I20181114-1345 > > > Andrey, any tips to recreate this on build I20181114-1345? I will try to do this over the weekend (I see it on my private Windows notebook only). Just to be sure: I'm still using Java 8 as my runtime JDK, if this is important to reproduce. May be some installed plugins are guilty (I have SDK + few selected, see attached file which you can import into your SDK). But this can be really dependent on the opened workspace projects - I have different workspaces on Windows/Linux workstations, and I see this only on Windows one.
So tried the latest nightly build, still the same issue (tons of errors like that) : null org.eclipse.pde.api.tools Error Sun Nov 18 20:45:55 CET 2018 Error logged from API Tools Core: org.eclipse.core.runtime.CoreException: Unable to resolve superclass org.eclipse.core.runtime.CoreException for org.eclipse.debug.core.DebugException at org.eclipse.pde.api.tools.internal.model.ApiType.getSuperclass(ApiType.java:278) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.collectAllInterfaces(ClassFileComparator.java:886) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getInterfacesSet(ClassFileComparator.java:2008) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.checkSuperInterfaces(ClassFileComparator.java:300) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getDelta(ClassFileComparator.java:1140) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator$2.visit(ApiComparator.java:774) at org.eclipse.pde.api.tools.internal.model.ArchiveApiTypeContainer.accept(ArchiveApiTypeContainer.java:204) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.internalCompare(ApiComparator.java:659) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare(ApiComparator.java:289) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare(ApiComparator.java:315) at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.checkCompatibility(BaseApiAnalyzer.java:1446) at org.eclipse.pde.api.tools.internal.builder.BaseApiAnalyzer.analyzeComponent(BaseApiAnalyzer.java:258) at org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.buildAll(ApiAnalysisBuilder.java:787) at org.eclipse.pde.api.tools.internal.builder.ApiAnalysisBuilder.build(ApiAnalysisBuilder.java:372) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:833) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:220) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:263) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:316) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:45) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:319) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:371) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:392) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:154) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:244) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) I've closed all projects except org.eclipse.jdt.debug org.eclipse.jdt.debug.ui org.eclipse.debug.core org.eclipse.debug.ui I assumed something with the 4.9 baseline I have doesn't work, so I've re-created it using 4.10 PDE from 4.9 Windows SDK, with no success, still errors.
Unable to recreate with org.eclipse.jdt.debug org.eclipse.jdt.debug.ui org.eclipse.debug.core org.eclipse.debug.ui on Version: 2018-12 (4.10) Build id: I20181114-1345 I used both IBM 1.8 and oracle 1.8 JRE. Are you consistently able to recreate or does it happen once in a while ( on I20181114-1345 which has logging enabled)
(In reply to Vikas Chandra from comment #32) > Unable to recreate with > > > org.eclipse.jdt.debug > org.eclipse.jdt.debug.ui > org.eclipse.debug.core > org.eclipse.debug.ui > > on > Version: 2018-12 (4.10) > Build id: I20181114-1345 > > I used both IBM 1.8 and oracle 1.8 JRE. > > > Are you consistently able to recreate or does it happen once in a while ( on > I20181114-1345 which has logging enabled) Yes, I consistently see it with Build id: I20181117-0600 (I've enabled tracing). I've already recreated JDT index few times and re-built the API baseline from scratch, so it must be something else. The workspace I use is pretty old one, where I usually do all the SDK work. While writing this, I've realized that one thing is always workspace related is "External Plugin Libraries Project" which I've now deleted and everything seem to work now. Can it be, that some "old" bundles were found in that project? If yes, how they are cleaned up, if they are cleaned up at all?
I tried with that 4 plugins and "External Plugin Libraries Project" and still I was unable to recreate this. Can you try with a fresh workspace ( with tracing enabled) and find a way to consistently recreate it. That should help me fix this.
Tried again. Still unable to recreate it !
I tried to put a breakpoint on CoreException ( caught and uncaught) and ran API analysis and I was unable to recreate this.
New Gerrit change created: https://git.eclipse.org/r/138877
Gerrit change https://git.eclipse.org/r/138877 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=f9eab08330d86c6afcf11c37b3b0a49a97c9c664
(In reply to Eclipse Genie from comment #38) > Gerrit change https://git.eclipse.org/r/138877 was merged to [master]. > Commit: > http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/ > ?id=f9eab08330d86c6afcf11c37b3b0a49a97c9c664 After this patch (still observing tons of errors) my stack shows that the PDE always fails here (for all "Problems encountered comparing class file" errors it reports during API build): IApiComponent[] components = getApiComponent().getBaseline().resolvePackage(getApiComponent(), packageName); if (components == null || components.length == 0) { throw new CoreException(createUnresolvedSuperClassStatus(qName)); } So why should the baseline not have the packages like org.eclipse.jface.viewers or org.eclipse.core.runtime or other gazillion of packages? org.eclipse.core.runtime.CoreException: Unable to resolve superclass org.eclipse.jface.viewers.ISelectionProvider for org.eclipse.compare.CompareViewerPane at org.eclipse.pde.api.tools.internal.model.ApiType.resolveSuperType(ApiType.java:293) at org.eclipse.pde.api.tools.internal.model.ApiType.getSuperInterfaces(ApiType.java:259) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.collectAllInterfaces(ClassFileComparator.java:867) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.collectAllInterfaces(ClassFileComparator.java:887) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getInterfacesSet(ClassFileComparator.java:2021) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.checkSuperInterfaces(ClassFileComparator.java:300) at org.eclipse.pde.api.tools.internal.comparator.ClassFileComparator.getDelta(ClassFileComparator.java:1153) at org.eclipse.pde.api.tools.internal.provisional.comparator.ApiComparator.compare(ApiComparator.java:430)
>> why should the baseline not have the packages like org.eclipse.jface.viewers >>or org.eclipse.core.runtime or other gazillion of packages? The baseline also has the dependent plugins/packages for API tool analysis .
(In reply to Vikas Chandra from comment #40) > >> why should the baseline not have the packages like org.eclipse.jface.viewers >>or org.eclipse.core.runtime or other gazillion of packages? > > > The baseline also has the dependent plugins/packages for API tool analysis . If it was a question: I *hope*. I've created baseline from an extracted Eclipse SDK zip. Whatever tooling got from that SDK build should be in the baseline, and I assume such basic things like org.eclipse.core.runtime should be available.
I thought I had answered the question but looks like I misunderstood your question. Can you give steps for comment#39. I will investigate and let you know.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
