Community
Participate
Working Groups
If you have duplicate source for a classfile, the duplicate source files found dialog does not indicate the full location of the duplicates. For example, the JAR should be indicated as well as the package name (which may be the same).
To be addressed with new source lookup, not old.
Fixed in new source lookup impl (thus, currently testable in Java apps, applets, and remote Java apps).
Please verify, Darin (S).
Now I get a dialog that shows me two class names that are identical. I have no way to tell which is which? As well clicking "Cancel" seems to pick one and show the source for it?
What's your test case? I was using an external zip and a project that had the same source. The dialog shows the file name followed by it's container name (i.e. xxxxx.java - somewhere/else/...). What type of launch config?
I put the ant.jar on the build path twice from two different locations. I then have a Java app that creates an echo task and executes it. Stepping into the echo class, I get prompted but all that is listed is "Echo.class" twice.
Will investigate
Ah, I see - but I'm not sure how to fix it. The two classes are on the buildpath as java elements, and are rendered with their IWorkbenchAdapter, which I cannot configure (from the platform, we have no notion of the java workbench adapater). Thus, they show up with default rendering (unqaulified). It works if you put the source zips on the source lookup path (rather than the buildpath).
Deferred
*** Bug 123013 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
*** Bug 454556 has been marked as a duplicate of this bug. ***
Reopening after bug 454556.
Created attachment 249815 [details] WorkbenchAdapter to append rootpath to labels Added Workbench Adapter extending the existing JavaWorkbenchAdapter form JDTUI to append root path to the labels for JavaElements.
Comment on attachment 249815 [details] WorkbenchAdapter to append rootpath to labels This does not compile: you are using getJavaElement(element), but this is a private method.
Created attachment 249920 [details] Debug WorkbenchAdapter to append rootpath to labels Removed the dependency on JavaWorkbenchAdapter from jdt.ui. Added a new Java Debug Workbench Adapter which provide the appended labels for duplicate sources.
Fixed with http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=e644421b4528ce8a3c5bad32d7f02f37050a42bd
Verified using Eclipse SDK Version: Mars (4.5) Build id: I20150126-2000
This caused bug 460234. I've reverted the fix with http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=dc0bcc9d1c4dd8e91321d26a56136d746d0e3ba3 Not sure how I oversaw this: the fix overwrote JDT UI's workbench adapter. This is not good.
(In reply to Dani Megert from comment #19) > This caused bug 460234. I've reverted the fix with > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > ?id=dc0bcc9d1c4dd8e91321d26a56136d746d0e3ba3 > > Not sure how I oversaw this: the fix overwrote JDT UI's workbench adapter. > This is not good. the patch was implementing IWorkbenchAdapter and not extending JDT UI Workbench Adapter. I ma not sure, how are these two related. I don't see the Project properties problem in the latest I build. Eclipse SDK Version: Mars (4.5) Build id: I20150217-0800
(In reply to Sarika Sinha from comment #20) > (In reply to Dani Megert from comment #19) > > This caused bug 460234. I've reverted the fix with > > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/ > > ?id=dc0bcc9d1c4dd8e91321d26a56136d746d0e3ba3 > > > > Not sure how I oversaw this: the fix overwrote JDT UI's workbench adapter. > > This is not good. > > the patch was implementing IWorkbenchAdapter and not extending JDT UI > Workbench Adapter. I ma not sure, how are these two related. + <factory + class="org.eclipse.jdt.internal.debug.ui.sourcelookup.WorkbenchAdapterFactory" + adaptableType="org.eclipse.jdt.core.IJavaElement"> + <adapter type="org.eclipse.ui.model.IWorkbenchAdapter"/> + </factory> This overwrites the contribution from JDT UI. > I don't see the > Project properties problem in the latest I build. > Eclipse SDK > > Version: Mars (4.5) > Build id: I20150217-0800 Please try again, but make sure JDT Debug is not loaded. Hint: use a new workspace and follow the steps from the other bug.
Created attachment 252111 [details] Java Resolve Source Duplicate Handler with Label Provider
Created attachment 252112 [details] To provide different status handlers for resolving source duplication Have added a new Status handler and label handler for Java. It extends the features provided by Platform Debug. Platform debug has added the ability for components to add different status handlers for resolving duplicate source elements.
(In reply to Sarika Sinha from comment #22) > Created attachment 252111 [details] [diff] > Java Resolve Source Duplicate Handler with Label Provider I don't like that fix. It uses internal code, connects two bundles with a random status code (206), and duplicates code.
As there was no API, I had to duplicate some code, I can create an enhancement to open up the API to enable adding status handlers. Even in the platform debug, status code is used to bind two bundles.
(In reply to Sarika Sinha from comment #25) > As there was no API, I had to duplicate some code, I can create an > enhancement to open up the API to enable adding status handlers. > Even in the platform debug, status code is used to bind two bundles. If we consider adding API, then I would assume there's an easier way to achieve what we need.
(In reply to Dani Megert from comment #26) > (In reply to Sarika Sinha from comment #25) > > As there was no API, I had to duplicate some code, I can create an > > enhancement to open up the API to enable adding status handlers. > > Even in the platform debug, status code is used to bind two bundles. > > If we consider adding API, then I would assume there's an easier way to > achieve what we need. We can fix this along the lines of comment 14, but instead of providing an IWorkbenchAdapter we provide an org.eclipse.debug.internal.ui.sourcelookup.SourceElementLabelProvider. SourceElementLabelProvider#getText needs to first ask for that adapter. If we don't want to use internals (we already do in plugin.xml), we can add an interface, e.g. ISourceElementLabelProvider during 4.6.
Created attachment 252338 [details] JDT SourceElementLabelProvider Adapter
Created attachment 252343 [details] Platform SourceElementLabelProvider Adapter Platform patch provides a way to adapt to SourceElementLabelProvider. JDT patch adds an adapter for SourceElementLabelProvider to provide appropriate text and Image.
(In reply to Sarika Sinha from comment #29) > Created attachment 252343 [details] [diff] > Platform SourceElementLabelProvider Adapter > > Platform patch provides a way to adapt to SourceElementLabelProvider. JDT > patch adds an adapter for SourceElementLabelProvider to provide appropriate > text and Image. The name "JavaDebugSourceElementLabelProviderAdapter" is not good. We usually use the same (or similar) name as the adapter in the plugin.xml. Please put all changes into one patch to reduce overhead. JavaPlugin is internal and should be avoided.
Changes done as mentioned in Comment #30 http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5bf216ac8b8307249a76f9dd13301f7f070b0cb8 http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=8f3b5f58c650f767e3cd133df991cf0f2e6c47f7
(In reply to Sarika Sinha from comment #31) > Changes done as mentioned in Comment #30 > http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=5bf216ac8b8307249a76f9dd13301f7f070b0cb8 > > http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=8f3b5f58c650f767e3cd133df991cf0f2e6c47f7 > I've did a minor code cleanup with http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=fb583bc76c41e7bc31536936af8ff34f0b170681
Verified using Eclipse SDK Version: Mars (4.5) Build id: I20150426-2000
