Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Debug Platform/Planning"
m (→Workflow) |
m |
||
(13 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
This page is gathering place of ideas for the future evolution of the Eclipse debug platform (3.*, and e4). | This page is gathering place of ideas for the future evolution of the Eclipse debug platform (3.*, and e4). | ||
− | + | == Debug Platform 3.5 == | |
− | * | + | == M2 == |
− | * | + | * '''Reliability''' |
− | * | + | **; [http://bugs.eclipse.org/242489 242489] : Create a framework based on the virtual viewer that simulates the common debugger views and validates debug model's content providers. (Pawel Piech) |
+ | * '''Platform''' | ||
+ | *; [http://bugs.eclipse.org/212316 212316] : Make it easier to create different breakpoint types from the same editor. | ||
+ | *; [http://bugs.eclipse.org/229219 229219] : Allow command framework handlers easy access to active debug context. | ||
− | == | + | == M3 == |
+ | * '''Workflow''' | ||
+ | ** ''Debugging without the debug view or debug perspective'' | ||
+ | **; Active debug context switcher : Create a lightweight mechanism for switching and reporting the active debug context (Pawel Piech). | ||
+ | **; Debug toolbar : Add a top-level toolbar for Debug actions (Pawel Piech). | ||
− | + | * '''Platform Enhancements''' | |
− | * '' | + | *; [http://bugs.eclipse.org/213074 213074] : Make run to line adapter async. |
− | *; [http://bugs.eclipse.org/ | + | *; [http://bugs.eclipse.org/244059 244059] : Allow breakpoints to specify when they should be overwritten on import |
− | *; [http://bugs.eclipse.org/ | + | *; [http://bugs.eclipse.org/236980 236980] : [launching] Support ILaunchConfigurations on EFS |
− | *; | + | |
− | + | * '''JDT Enhancements''' | |
− | + | ** '''Execution Environments''' : Support for custom execution environments. This is a joint effort between OSGi, JDT, and PDE. OSGi needs support for contributing OSGi profile definitions. JDT needs to be able to reference those profiles (connect an .ee file to an OSGi profile), PDE needs to be able to set compiler options based on an OSGi profile, and API tooling needs to be able to understand the profile definitions as well to build a system library component. | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | == | + | == M4 == |
− | * '' | + | * '''Reliability''' |
− | * | + | ** Rework performance test suite to make relevant/stable test cases |
− | * | + | * '''Workflow''' |
− | + | ** ''Memory View'' | |
− | * '' | + | **; [http://bugs.eclipse.org/244822 244822] : streamline memory view workflow & reduce UI clutter (Ted Williams, Wind River) |
− | * | + | |
− | + | ||
− | + | ||
− | * '' | + | |
− | * | + | |
− | *; [http://bugs.eclipse.org/ | + | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | === | + | ** ''Multiple-context debugging'' |
− | *; | + | **; Debug working sets : Implement a mechanism to let the user group a sub-set of debug contexts, and then use this sub-set to drive content of debugger views. A color, label, and a decorator could be used to identify the working set. |
− | *; | + | **; Multiple instances of debugger views : Allow user to create multiple instances of Variables, Registers and other debugger views. To make this feature useful, also allow the user to select the input debug context for the views. |
+ | |||
+ | == M5 == | ||
+ | |||
+ | |||
+ | == Debug Platform 3.* == | ||
+ | |||
+ | * '''Modularity''' | ||
+ | ** ''Asynchronous viewer framework '' | ||
+ | **; [http://bugs.eclipse.org/161435 161435] : Contribute asynchronous viewer to JFace. | ||
+ | **; [http://bugs.eclipse.org/242489 242489] : Create a virtual viewer implementation for use in tests, debug search, and a view-less active context provider. | ||
+ | **; DSF View Model implementation for standard debug model : Prototype a standard debug model/flexible hierarchy integration using DSF View Model (Pawel Piech). | ||
+ | |||
+ | * '''Platform''' | ||
+ | *; Spawner : Contribute process "Spawner" from CDT to platform, to support process IDs and system signals (Darin Wright). | ||
+ | *; [http://bugs.eclipse.org/175538 175538] : Allow plug-ins to extend/modify/cancel launches. | ||
+ | *; CDT breakpoint actions : Move breakpoint actions from CDT to the platform (Ken Ryall). | ||
+ | *; Launch configurations in EFS : Support EFS (external file system) for launch configuration persistence (Darin Wright). | ||
+ | |||
+ | * '''Workflow''' | ||
+ | ** ''Debugging without the debug view or debug perspective'' | ||
+ | **; Debug dashboard : Create a lightweight variables view or "debug dashboard" (requested by ?). | ||
+ | ** ''Debugger tooltip enhancements'' | ||
+ | **; Instant debugger tooltips : Implement debugger tooltips as "instant debugger tooltips", which appear without waiting for operating system delay (Mike Morearty). | ||
+ | **; Tooltip updates : Each time you step, tooltip automatically refreshes the displayed value (Mike Morearty). | ||
+ | **; In-line expressions editing : In the Expressions view, allow user to click or double-click to add or edit expressions in-line, without opening a dialog (Mike Morearty). | ||
+ | ** ''Breakpoints presentation'' | ||
+ | **; [http://bugs.eclipse.org/238954 238954] : Decorate breakpoints according to active debug context. | ||
+ | **; [http://bugs.eclipse.org/238956 238956] : Improve usability of the breakpoints view. | ||
+ | ** ''Multiple-context debugging'' | ||
+ | **; Debugging with multiple editors visible : Allow debugger to manage the editor area to display multiple debug sessions simultaneously. | ||
+ | |||
+ | * '''Reliability''' | ||
+ | **; Performance tests : Create more meaningful performance tests and backport to 3.4 | ||
== Debug Platform e4 == | == Debug Platform e4 == | ||
− | + | * '''Modularity''' | |
− | ; Services : Use services instead of singletons (launch manager, expression manager...) | + | *; Services : Use services instead of singletons (launch manager, expression manager...) |
− | ; Launch Framework : Separate launching into a new component, that can be used without debug | + | *; Launch Framework : Separate launching into a new component, that can be used without debug |
− | ; DSF : Moving forward what happens to the standard debug model? DSF? | + | *; DSF : Moving forward what happens to the standard debug model? DSF? |
− | + | * '''Platform''' | |
− | * ''Improve launch framework'' | + | ** ''Improve launch framework'' |
− | *; Launch APIs : Consolidate/simplify launching APIs (mixed mode, launch shortcuts, contextual launch) | + | **; Launch APIs : Consolidate/simplify launching APIs (mixed mode, launch shortcuts, contextual launch) |
− | *; Decouple launch configurations : Should we continue to use launch configurations, or consider an architecture that would allow aspects of a launch be used more easily to compose different types of launch configurations (e.g. JRE, Source lookup...) | + | **; Decouple launch configurations : Should we continue to use launch configurations, or consider an architecture that would allow aspects of a launch be used more easily to compose different types of launch configurations (e.g. JRE, Source lookup...) |
− | *** How can we make the UI for a launch aspect more reuseable? | + | **** How can we make the UI for a launch aspect more reuseable? |
− | *; External tools : Merge external tools with run/debug | + | **; External tools : Merge external tools with run/debug |
− | *; Multi-launch : Support for multi-launch | + | **; Multi-launch : Support for multi-launch |
− | *; Get rid of StreamsProxy : Provide direct access to a process's input/output streams (no need for StreamsProxy) | + | **; Get rid of StreamsProxy : Provide direct access to a process's input/output streams (no need for StreamsProxy) |
− | *; Launch configuration namespaces : Namespace for launch configurations should not be flat | + | **; Launch configuration namespaces : Namespace for launch configurations should not be flat |
Latest revision as of 11:40, 22 August 2008
This page is gathering place of ideas for the future evolution of the Eclipse debug platform (3.*, and e4).
Debug Platform 3.5
M2
- Reliability
- 242489
- Create a framework based on the virtual viewer that simulates the common debugger views and validates debug model's content providers. (Pawel Piech)
- Platform
M3
- Workflow
- Debugging without the debug view or debug perspective
- Active debug context switcher
- Create a lightweight mechanism for switching and reporting the active debug context (Pawel Piech).
- Debug toolbar
- Add a top-level toolbar for Debug actions (Pawel Piech).
- Debugging without the debug view or debug perspective
- Platform Enhancements
- JDT Enhancements
- Execution Environments : Support for custom execution environments. This is a joint effort between OSGi, JDT, and PDE. OSGi needs support for contributing OSGi profile definitions. JDT needs to be able to reference those profiles (connect an .ee file to an OSGi profile), PDE needs to be able to set compiler options based on an OSGi profile, and API tooling needs to be able to understand the profile definitions as well to build a system library component.
M4
- Reliability
- Rework performance test suite to make relevant/stable test cases
- Workflow
- Memory View
- 244822
- streamline memory view workflow & reduce UI clutter (Ted Williams, Wind River)
- Memory View
- Multiple-context debugging
- Debug working sets
- Implement a mechanism to let the user group a sub-set of debug contexts, and then use this sub-set to drive content of debugger views. A color, label, and a decorator could be used to identify the working set.
- Multiple instances of debugger views
- Allow user to create multiple instances of Variables, Registers and other debugger views. To make this feature useful, also allow the user to select the input debug context for the views.
- Multiple-context debugging
M5
Debug Platform 3.*
- Modularity
- Asynchronous viewer framework
- 161435
- Contribute asynchronous viewer to JFace.
- 242489
- Create a virtual viewer implementation for use in tests, debug search, and a view-less active context provider.
- DSF View Model implementation for standard debug model
- Prototype a standard debug model/flexible hierarchy integration using DSF View Model (Pawel Piech).
- Asynchronous viewer framework
- Platform
- Spawner
- Contribute process "Spawner" from CDT to platform, to support process IDs and system signals (Darin Wright).
- 175538
- Allow plug-ins to extend/modify/cancel launches.
- CDT breakpoint actions
- Move breakpoint actions from CDT to the platform (Ken Ryall).
- Launch configurations in EFS
- Support EFS (external file system) for launch configuration persistence (Darin Wright).
- Workflow
- Debugging without the debug view or debug perspective
- Debug dashboard
- Create a lightweight variables view or "debug dashboard" (requested by ?).
- Debugger tooltip enhancements
- Instant debugger tooltips
- Implement debugger tooltips as "instant debugger tooltips", which appear without waiting for operating system delay (Mike Morearty).
- Tooltip updates
- Each time you step, tooltip automatically refreshes the displayed value (Mike Morearty).
- In-line expressions editing
- In the Expressions view, allow user to click or double-click to add or edit expressions in-line, without opening a dialog (Mike Morearty).
- Breakpoints presentation
- Multiple-context debugging
- Debugging with multiple editors visible
- Allow debugger to manage the editor area to display multiple debug sessions simultaneously.
- Debugging without the debug view or debug perspective
- Reliability
- Performance tests
- Create more meaningful performance tests and backport to 3.4
Debug Platform e4
- Modularity
- Services
- Use services instead of singletons (launch manager, expression manager...)
- Launch Framework
- Separate launching into a new component, that can be used without debug
- DSF
- Moving forward what happens to the standard debug model? DSF?
- Platform
- Improve launch framework
- Launch APIs
- Consolidate/simplify launching APIs (mixed mode, launch shortcuts, contextual launch)
- Decouple launch configurations
- Should we continue to use launch configurations, or consider an architecture that would allow aspects of a launch be used more easily to compose different types of launch configurations (e.g. JRE, Source lookup...)
- How can we make the UI for a launch aspect more reuseable?
- External tools
- Merge external tools with run/debug
- Multi-launch
- Support for multi-launch
- Get rid of StreamsProxy
- Provide direct access to a process's input/output streams (no need for StreamsProxy)
- Launch configuration namespaces
- Namespace for launch configurations should not be flat
- Improve launch framework