[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-debug-dev] Debug Work Items for 2.1 and Beyond
|
Here is an initial list of things we would like to see in 2.1 (some people
are away on vacation and they may have more to add).
1. A way for debug targets wrappering JDT to inherit the features of JDT
and not have to re-implement them (see bugzilla bug 21823)
2. Some way to be able to turn off features of JDT that we do not want
supported. For example when debugging WAS the user only wants to debug
their web objects and not the WAS runtime. To deal with this a step filter
preference page was added which has a much larger list of default filters
than the JDT step filter page. In addition to setting the JDT step filters
with these defaults the WAS debug adapter also uses the filters to skip
over WAS runtime code when the user steps out of their web object (e.g.
there is WAS runtime code called when one web object calls another). The
problem that arises from this is if the user changes the JDT step filter
preferences while debugging using the WAS debug adapter or clicks the
enable/disable step filters action each of which will override the JDT step
filtering settings that the WAS debug adapter had set up. On the other
hand some JDT wrappering debug adapters may want this feature enabled.
3. Better support in JDT for standalone debugging. This is important for
customers who have purchased WAS but not WSAD, as they are less likely to
have all of their code in eclipse projects. Also there does not seem to be
an easy way of getting existing code into projects. The import file system
feature of eclipse sometimes treats .java files as regular files and
sometimes as compilation units. Problems that arise from this are:
Depending on how the file system is imported, breakpoints cannot be
set on .java files. It seems that JDT only recognizes .java files
that are in a package.
JDT will try to compile some of the .java files (if they are in the
base directory that was imported). It then shows errors for these
files. This is not very nice from a user point of view. It also
causes another problem in that inspect/display of variables will not
work on a source file that has compile errors.
The JDT source locator only finds source if it is recognized as a
compilation unit, if the .java file is a regular file the source
locator will not find it.
4. Externalize the SourceLookupDialog from the JavaUISourceLocator. We
would like to be able to bring up the same dialog if we fail to find a .jsp
file or other file that we cannot search for using the JDT source locator.
5. The problem already identified in a previous note from Darin where some
of the debug event listeners create async runnables to handle a debug event
but when they are run the debug model is no longer in the same state as
when the event was reported. This has hit us a few times.
6. Currently we create a fake launch and pass it to
JDIDebugModel.newDebugTarget to avoid the JDIDebugTarget being added to the
real launch. Is there possibly a better way to do this?
7. It would be nice if when the source locator returns null, a file could
be shown which contains only "No Source" or something like it. User's seem
to find it confusing to step around stack frames, some of which have no
source available, and have it continue to show the source for the previous
stack frame. Each source locator could implement this individually but it
seems to make more sense to do it in one spot. Individual source locators
can still override this by returning their own "empty" file if they want.
8. Sometimes we want to show our own label for threads and sometimes we
want to show the JDT label. For example when the user asks to step and in
order to accomplish this we set a hidden Java breakpoint and tell the Java
thread to run, we want in this case to show our own label for the thread.
When a Java breakpoint is hit, however we want to use the Java label rather
than have to recreate the labels for all of the different Java breakpoint
types (watchpoint, line, method, exception). It would be nice if there was
some way to ensure that the labels at least had the same format (even if
the JDT format changes). This is probably not a big concern if you don't
expect the format to change.
9. There are a number of menu items on the Run menu that are "unfriendly"
when using non-Java debug adapters. Some of them are things that users
might want / expect to use, but they are only available with Java. Because
the wording is very general (e.g. Run to line) it is not obvious to the
user that it applies to Java only.
- "Run To Line" - This would be a nice feature for most debug adapters,
but the option is only available for Java debug targets. They should make
the option only show up for Java debug targets, make the action available
to other debug targets, or change the wording to make it clear that it is
only available for Java.
- "Add/Remove Breakpoint Ctrl+Shift+B" - Again, this would be a nice
feature for most debug adapters and should be made available generally or
reworded to indicate Java only.
- "Add/Remove Method Breakpoint" - ditto
- "Add/Remove Watchpoint" - ditto
- "Run Snippet" - Maybe this could be reworded to make it clear that it
only applies to Java Snippets.
10. It would be nice if the Variables view could retain the expansion tree
for more than one stack frame, and if the expansion wasn't lost every time
you run. This is a real annoyance with EGL as almost everything is a
structure, and you almost always have to expand a variable to see the
meaningful data. I think Alan Boxall had made some suggestions for this
(e.g. each stack frame could store the expansion, and the Variables view
queries the stack frame for the expansion to use and saves the current
expansion when the stack frame is deselected).
11. It would be nice if IDebugModelPresentation.getEditorInput() and
IDebugModelPresentation.getEditorId() were passed a stack frame. The
reason for this is that if the WAS model presentation gets an Object that
we do not know how to handle (something returned by the JDT source locator)
then we can get the model identifier for the sub stack frame and call
getEditorInput or getEditorId on that model presentation. Currently we
directly call the JDT model presentation, however if the EGL debug adapter
is stacked on top of JDT then we would like to call it first (we don't
actually keep track of it, but provide an extension point instead which
debug adapters that wrapper JDT can extend if they want to be part of WAS
debug).
Erin
----- Forwarded by Erin Harris/Toronto/IBM on 08/14/2002 11:21 AM -----
"Darin Wright"
<Darin_Wright@xxxxxxx> To: platform-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin@ Subject: Re: [platform-debug-dev] Debug Work Items for 2.1 and Beyond
eclipse.org
08/12/2002 04:31 PM
Please respond to
platform-debug-dev
Not yet. We are still eagarly waiting for input from other developers to
help prioritize the features we will work on. If there are any
features/bugs/issues that are important to you, please let us know.
Darin
eharris@xxxxxxxxxx
Sent by: To:
platform-debug-dev-admin@ec platform-debug-dev@xxxxxxxxxxx,
lipse.org jdt-debug-dev@xxxxxxxxxxx
cc:
Subject:
08/12/2002 03:22 PM [platform-debug-dev] Debug Work Items for
Please respond to 2.1 and Beyond
platform-debug-dev
Is there any update on which of the possible work items are going into 2.1?
Thanks.
Erin
----- Forwarded by Erin Harris/Toronto/IBM on 08/12/2002 04:18 PM -----
"Darin Wright"
<Darin_Wright@xxxxxxx> To:
platform-debug-dev@xxxxxxxxxxx, jdt-debug-dev@xxxxxxxxxxx
Sent by: cc:
platform-debug-dev-admin@ Subject:
[platform-debug-dev] Debug Work Items for 2.1 and Beyond
eclipse.org
07/17/2002 09:04 AM
Please respond to
platform-debug-dev
The Debug Team is planning its work items/feature set for the 2.1 and
future releases of Eclipse. Attached is an HTML document with a list of
potential work items. We encourage interested parties to add any features,
requirements, or issues that they feel are important, or which could be
investigated. Note that items on the list are not committed to any
particular release of Eclipse (and may not even be technically possible).
Once we have a complete list, we can vote on the priority of the work
items, to determine what will actually go into 2.1.
The document is also availabe in the "dev.eclipse.org" CVS repository, in
the "jdt-debug-home" project. Committers can add to the document, and post
to the debug mailing lists. Non committers please post to the debug mailing
lists.
Thanks,
Darin
**** Attachment DebugDirections2.1.htm has been removed from this note on
12 August 2002 by Erin Harris ****
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-debug-dev
