Bugzilla – Full Text Bug Listing
| Summary: | [context] Java class that is a landmark isn't showing up in package explorer | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | David Green <greensopinion> | ||||||||||
| Component: | Mylyn | Assignee: | Shawn Minto <shawn.minto> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | critical | ||||||||||||
| Priority: | P1 | CC: | awi, mik.kersten, steffen.pingel | ||||||||||
| Version: | dev | ||||||||||||
| Target Milestone: | 3.2 | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
David Green
David, can you enable the interest decorator (in the Sandbox) and check if the class shows up on the Context tab of the task editor? (In reply to comment #1) > David, can you enable the interest decorator (in the Sandbox) and check if the > class shows up on the Context tab of the task editor? sure... how do I enable the interest decorator? It doesn't show up on the Context tab of the task editor unless I move the slider all the way to the left. If you install the Sandbox, you can enable "Experimental: Interest Debugging Decorations" under Preferences > General > Appearance > Label Decorations. What happens if you mark the class itself as a landmark? (In reply to comment #4) > If you install the Sandbox, you can enable "Experimental: Interest Debugging > Decorations" under Preferences > General > Appearance > Label Decorations. I'll give it a try > What happens if you mark the class itself as a landmark? the class is already marked as a landmark, as is one of its methods (In reply to comment #4) > If you install the Sandbox, you can enable "Experimental: Interest Debugging Decorations" By Sandbox do you mean org.eclipse.mylyn.sandbox.ui_feature? I've got it installed and I don't see the "Experimental: Interest Debugging Decorations" label decorator. Sorry, my mistake, the decorator is contributed by the sandbox dev plug-in which is only available from source. Unless the context contains private information you can also send it to me and I can have a look with Shawn as to why the interest on the class is lower than expected. David, can you see if you can reproduce this problem with the latest 3.2 build as there have been changes to how the interest propagation works. This just happened again with Mylyn 3.2.0.I20090531-0500-e3x David, Is there any way that you would be able to provide a screenshot with the interest debugging decorator on showing the java file (unfiltered) or provide the entire context that this is happening on? sure. Can you remind me how to export the task context? I can't seem to find it in the context menu. The easiest way is to get the context from the workspace directory on the filesystem: .metadata/.mylyn/context/<taskHandle>.xml.zip (In reply to comment #12) That's not very useful when using JIRA where the task handle doesn't correspond to the task id. (In reply to comment #13) > (In reply to comment #12) > > That's not very useful when using JIRA where the task handle doesn't correspond > to the task id. Did your comment end up on the wrong bug? For JIRA the "Copy ID" action copies the user-friendly key, not the id. (In reply to comment #14) > Did your comment end up on the wrong bug? No, the comment is on the right bug. Shawn was suggesting that I can get a copy of the task context by looking for a file named something like this: bq. .metadata/.mylyn/context/<taskHandle>.xml.zip That's not very helpful since I have no way of associating the task handle with the context that I'm interested in for a JIRA task, since I know the task by it's well-known id (eg: NB-1234), not by some internally used number (eg: https%3A%2F%2Fportal.maketechnologies.com%2Fjira-32796.xml.zip) Oh, I see. Then the easiest way is to attach it to the JIRA bug and download it from there I guess. I think an export context action would make sense. David, can you try to reproduce with the latest RC as I fixed a problem with interest propagation. David, have you had a chance to try with the latest Mylyn build? (In reply to comment #18) > David, have you had a chance to try with the latest Mylyn build? Sorry for taking so long to get back to you. I don't have a reproducible test case and I've forgotten which issue was demonstrating the issue. As soon as I see the problem again I'll let you know. I'll mark this resolved for now then. David, please reopen if you see it again. the problem still occurs. Is it possible that this problem is a misunderstanding on my part of how working sets are supposed to work? If a working set is selected, are all items in a context supposed to appear, or just those that are not filtered by the working set? If a view is focused the working set filter is automatically disabled. All items that are in the context will show regardless of the selected working set. Thanks... I just noticed that even with the working set disabled the Java elements still aren't showing up. David, The fix that was implemented will not fix any of your contexts, but will prevent it from happening in the future. Can you reproduce creating a scenario like this on the latest? What happens if you click on the file that you can't see while the task is active to make it get more interest? *** Bug 285714 has been marked as a duplicate of this bug. *** David, any news on this? (In reply to comment #27) > David, any news on this? no news. I'll keep you posted. Thanks. Please reopen if you see this problem again with a fresh context (comment 25). This has happened for me again. I'm not sure if it's related, but I found this in the error log: pre.. eclipse.buildId=M20090729-0903 java.version=1.6.0_13 java.vendor=Apple Inc. BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US Framework arguments: -keyring /Users/dgreen/.eclipse_keyring -showlocation Command-line arguments: -os macosx -ws cocoa -arch x86_64 -data /Users/dgreen/Documents/make/workspace-nbdh -keyring /Users/dgreen/.eclipse_keyring -showlocation Error Wed Aug 12 15:03:00 PDT 2009 Problems occurred when invoking code from plug-in: "org.eclipse.team.core". org.eclipse.core.runtime.AssertionFailedException: assertion failed: at org.eclipse.core.runtime.Assert.isTrue(Assert.java:110) at org.eclipse.core.runtime.Assert.isTrue(Assert.java:96) at org.eclipse.team.core.diff.provider.DiffTree.internalRemove(DiffTree.java:295) at org.eclipse.team.core.diff.provider.DiffTree.remove(DiffTree.java:163) at org.eclipse.team.core.mapping.provider.ResourceDiffTree.remove(ResourceDiffTree.java:179) at org.eclipse.team.internal.core.subscribers.DiffChangeSet.remove(DiffChangeSet.java:165) at org.eclipse.mylyn.internal.team.ui.ContextChangeSet.remove(ContextChangeSet.java:117) at org.eclipse.team.internal.core.subscribers.ActiveChangeSetManager.handleAddedResources(ActiveChangeSetManager.java:243) at org.eclipse.team.internal.core.subscribers.ActiveChangeSetManager.handleSyncSetChange(ActiveChangeSetManager.java:255) at org.eclipse.team.internal.core.subscribers.ActiveChangeSetManager.diffsChanged(ActiveChangeSetManager.java:97) at org.eclipse.team.core.diff.provider.DiffTree$1.run(DiffTree.java:247) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.team.core.diff.provider.DiffTree.fireChanges(DiffTree.java:239) at org.eclipse.team.core.diff.provider.DiffTree.endInput(DiffTree.java:221) at org.eclipse.team.internal.core.subscribers.DiffChangeSet.add(DiffChangeSet.java:103) at org.eclipse.mylyn.internal.team.ui.ContextChangeSet.add(ContextChangeSet.java:146) at org.eclipse.team.internal.core.subscribers.ActiveChangeSet.add(ActiveChangeSet.java:207) at org.eclipse.mylyn.internal.team.ui.ContextChangeSet.add(ContextChangeSet.java:151) at org.eclipse.mylyn.internal.team.ui.ContextActiveChangeSetManager.interestChanged(ContextActiveChangeSetManager.java:293) at org.eclipse.mylyn.context.core.AbstractContextListener.contextChanged(AbstractContextListener.java:129) at org.eclipse.mylyn.internal.context.core.InteractionContextManager$10.run(InteractionContextManager.java:1038) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.mylyn.internal.context.core.InteractionContextManager.notifyInterestDelta(InteractionContextManager.java:1029) at org.eclipse.mylyn.internal.context.core.InteractionContextManager.notifyInterestDelta(InteractionContextManager.java:1023) at org.eclipse.mylyn.internal.context.core.InteractionContextManager.processInteractionEvents(InteractionContextManager.java:1155) at org.eclipse.mylyn.internal.resources.ui.ResourceInterestUpdater.internalAddResourceToContext(ResourceInterestUpdater.java:81) at org.eclipse.mylyn.internal.resources.ui.ResourceInterestUpdater.access$0(ResourceInterestUpdater.java:65) at org.eclipse.mylyn.internal.resources.ui.ResourceInterestUpdater$1.run(ResourceInterestUpdater.java:52) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3404) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3101) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) This might be related to working sets. I cleared the context, opened the java file again and it still did not appear. Thinking that my active working set might be the cause, I clicked on the working set hyperlink in the task list. The working set dialog appeared showing selected resources and repositories. Inspecting these they looked fine. I pressed cancel on the dialog and all of a sudden the resources in the context reappeared in the package explorer. Can you check if the files are visible in the context tab of the task editor? If you have your package explorer configured to show Working Sets as top-level elements the problem could be related to bug 286415. (In reply to comment #32) > Can you check if the files are visible in the context tab of the task editor? Yes, they're visible. > If you have your package explorer configured to show Working Sets as top-level > elements the problem could be related to bug 286415. Does not apply to my configuration. This is becomming a real problem for me. When I activate a new JIRA task, use CTRL+Shift+T to open a Java class, the file does not appear in the Package Explorer. In fact, no Java files appear in the Package Explorer unless I disable the focus filter. This problem is occurring consistently with Mylyn 3.2.2.I20090812 but not with 3.2.0.v20090612 The problem is not JIRA-specific, it also occurs with Bugzilla tasks. Created attachment 144436 [details]
mylyn/context/zip
Thanks for the information David. There shouldn't be any difference between what kind of task as the context is task independent. The context that you attached seems to be corrupt in some way. Is this the one that was failing, or do you have another one that has the same problem? Created attachment 144573 [details]
screenshot showing package explorer and context
I've reproduced the problem again. This screenshot shows the problem, the problem context also attached.
Mylyn version 3.2.2.I20090812-0000-e3x
Created attachment 144574 [details]
mylyn/context/zip
(In reply to comment #39) > Created an attachment (id=144574) > mylyn/context/zip Just to be clear, that last attachment was a problem task context. David, do you have any other structure bridges than the standard Mylyn ones installed? If so, can you try to reproduce the problem with that one uninstalled? I see a resource/model kind in the attached context which leads me to think that there is a bridge installed that isn't working correctly (not to say that this couldn't still be a bug in one of the Mylyn bridges too). (In reply to comment #41) > David, do you have any other structure bridges than the standard Mylyn ones > installed? If so, can you try to reproduce the problem with that one > uninstalled? Yes I do, and I will. > I see a resource/model kind in the attached context which leads me > to think that there is a bridge installed that isn't working correctly (not to > say that this couldn't still be a bug in one of the Mylyn bridges too). There is a custom bridge installed, which has been working well for us for at least 18 months. There haven't been any changes to it in ages, and it was working without error. I'll uninstall it and see if the problem goes away. Created attachment 145317 [details]
another context that doesn't work
I've uninstalled the structure bridge as recommended and I can still reproduce the issue. Here's a simple one, attached.
I don't know much about the format of these files, but looking around I can see lots of attributes that have the value 'null'. I don't know if that's normal/expected.
Thanks for posting these contexts David. I will have to look at the context in more detail. Have you noticed a common set of steps to reproduce this when you see this? David, looking at the posted context in more detail, I do see a structure kind that is not a Mylyn kind, but only 1 entry for that one. However, I do see something weird with a couple Java elements showing up as a resource structure kind and the src folder is only in the resource model and not the java one. It would be great if you had some steps to cause this so that I can reproduce this and fix the core problem. David, I am resolving this as fixed again and moving it back to the original milestone as it seems to be a different problem. I have created the following bug to track the problem: 289259: [context] investigate potential failures with structure bridges https://bugs.eclipse.org/bugs/show_bug.cgi?id=289259 |