Bugzilla – Full Text Bug Listing
| Summary: | [launching] extensible launch options | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Darin Wright <darin.eclipse> | ||||||||||||||||||||||||||||
| Component: | Debug | Assignee: | Michael Rennie <Michael_Rennie> | ||||||||||||||||||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||||||||||||||||||
| Severity: | enhancement | ||||||||||||||||||||||||||||||
| Priority: | P3 | CC: | amehrega, andre_weinand, brockj, chanskw, ewchan, info, jkczyz, slavescu, tobias_widmer, vitaly, who | ||||||||||||||||||||||||||||
| Version: | 3.3 | ||||||||||||||||||||||||||||||
| Target Milestone: | 3.3 M4 | ||||||||||||||||||||||||||||||
| Hardware: | PC | ||||||||||||||||||||||||||||||
| OS: | Windows XP | ||||||||||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||||||||||
| Bug Depends on: | |||||||||||||||||||||||||||||||
| Bug Blocks: | 154107 | ||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||
|
Description
Darin Wright
Investigating for 3.3 Phase 1. Add in new extension point launchOptions to allow options to be contributed. The launch manager should be made aware of launch options and allow access to them via methods getLaunchOptions and getLaunchOption(id). A proxy was constructed to a contributed launch option, which is described with the ILaunchOption interface. For a complete description of API changes see the buildnotes for platform debug. Created attachment 50306 [details]
phase 2
this patch is a work in progress (phase 2).
Overview:
This phase was to convert all delegates to be treated as contributed delegates and to abstract the notion of a launch delegate from a launch configuration type. To do so, the attribute delegate on a launch config type was deprecated and moved to the launchDelegates extension point, where we have introduced the notion of one delegate being associated with more than one type.
The expression description of options was added to the launchDelegates extension point, which will allow us to determine what delegates can be use to launch what type with what options at any given time.
The launch manager (and API) was modified to work with the new notion of launch delegates.
The launchConfigurationTypeImages extension point was deprecated in favour of adding the icon in the launchConfigurationTypes extension point.
All existing launch capabilities are honoured with these API changes, including: 1. mode-specific launching
2. Launch delegates can still be acquired from contributed delegates or from launch config type contributions
3. config images can be contributed by the imgaes extension point or from the new attribute on the config type
All API changes are marked as experimental, and can be looked up in the build notes for debug.core.
Created attachment 50933 [details]
phase 3
This patch is the next in the series.
Overview:
1. provides new proxy classes for various configuration elements
2. allows delegate retargetting based on options
3. treats modes as first class options
4. provides accessor methods in LaunchManager for options and delegates
5. treats all launch delegates the same, no more distinct listing based on contribution
6. provided ability to contribute single (or more) tabs to an existing launch config tab group
7. contributed tabs can set options allowing them to retarget delegates
8. provided icon attribute for launchConfigurationType extension
9. deprecated launchConfigurationTypeImages extension point
For all details of additions/deletions/deprecations see the debug.core build notes
A development migration paper and example plugin project hae been posted at http://www.eclipse.org/eclipse/debug/documents.php Created attachment 51706 [details]
phase 4
this patch resolves issues revealed in the other patches such as:
1. more than one delegate provided for the same thing (type and options) are now flagged and the user is notified
2. launch manager is aware of duplicate delegates
Still required:
1. a pref page or the like for users to select default delegates in the event duplicates are found
*** Bug 133733 has been marked as a duplicate of this bug. *** Created attachment 51719 [details]
patch
Reviewed implementation. Comments:
* ConfigurationElementContants should be an interface instead of class (consistent style of IDebugUIConstants, etc.)
* Deprecation of sourcePathComputerId & sourceLocatorId is not consistent
- the launchDelegates schema and ILaunchConfigurationType specify that only one souce locator/path computer can be specified per type. Must allow > 1 to be contributed an update docs
* I removed the 'option' attribue from ILaunchOption since it's the same as the Id - just need label/id.
* I UN-deprecated the launch configuration images extension point. Still needed when image is in different plug-in than its type.
* I removed isValidLaunchOption(String)... can instead use getLaunchOption(String) and check for null return value
* ILaunchDelegate should be internal - its uses are all internal and clients don't need to know about it.
- also move ILaunchManager getLaunchDelegates() & getLaunchDelegates(String typeid, String mode, String[] options) to be internal methods on LaunchManager
* Similarly, ILaunchConfigurationTabExtension can be internal. It's just for implementation purposes.
Created attachment 51935 [details]
cleaned up
This patch cleans up the API and addresses reviewed comments.
This patch also provides the following:
1. bad option combination detection and resolution in the launch configuration dialog; via error message notification, a link to present solutions to the problem, and a dialog presenting the user with valid combinations of options for the current launching context.
2. bad option combination detection and resolution during launching. traditionally if a suitable launch delegate could not be found during launching (launched via shortcut menu or F11) the operation would only fail with an error message. Now a launch config edit dialog appears allowing users to edit the bad config on the fly and have launching continue (delegates can therefore be retargetted on the fly in this case).
3. a public abstract class for contributors to create launch config tabs that work with options, called AbstractOptionLaunchConfigurationTab.
Created attachment 51964 [details]
further
This patch adds in treating all options in the context of collections, and allows contributed tabs to describe their capabilities with groups of options instead of only one option
Created attachment 52144 [details]
refreshed patch
same patch but updated against HEAD
Released to HEAD with minor modifications. Made some larger modifications to allow true mixed mode launching. I have gotten rid of 'launch options'. A launch option is now just a mode. A configruation can have launch modes set on it (where you could previously set options options). When launching, the 'mode' parameter passed into the launch is which ever button the user pressed to start the launch. The launch then looks at the addition modes to consider (which are set on the config), and then launches in the mixed mode. A launch delegate still specifies the "modes" it supports, as primiary modes, and the additional modes it supports as "options". For example, to provide a launch delegate for profile that supports profiling in run or debug mode, it would specify "modes = profile" and "options = run, debug". The code needs to be enhanced to properly support missing delegates (i.e. if a config has a mode set on it for which there are no delegates) and for the case of more than one delegate. I have just checked out things from HEAD and played around a little bit. The contribution of launch configuration tabs works well. However, I think we should offer a mechanism to specifiy the relative location of the contributed pages. I guess ISVs are not very happy if their page can only be contributed at the far right on the tab group. Depending on screen resolution, those pages are not visible at first. What I would like to propose is a simple markup to specify before and after constraints for tabs, similar as it is done for the org.eclipse.ui.workbench.rulerColumns extension point. With this mechanism you are able to say that eg. a profile tab comes after the Java main tab, but before the non-java specific tabs in the group. Conflicting constraints could simply be ignored, and clashing ones resolved as in the rulerColumns extension point. As far as I understand from the current implementation and the preliminary documentation, only onelaunch delegate is finally selected to handle the actual launching. This means that exactly one basic mode (such as "run", "debug" or "profile") can be combined with one additional mode (such as "coverage" or "static_analysis"), right? If this is the case, this looks to me like an unwanted constraint. Why not have a solution which is more contribution-based, meaning that you rather add than replace? I would imagine that there is an extension point which lets clients define new launch modes such as "coverage" or "static_analysis", which then could be associated with existing launch configuration types (merged with the ones from the "modes" attribute of the "launchConfigurationTypes" extension point). The tab contributions would be orthogonal to the launch mode contributions, and clients could participate in the launching (eg. an ILaunchParticipant which extends the commandline with the mode-specific arguments based on the launch configuration) rather than overtake the launching via their own launch delegate. Depending on the additional modes added via ILaunchConfigurationWorkingCopy#addModes(Set), the launching framework would inform the participants registered for the particular modes, and the participants extend the commandline before the launch delegate performs the actual launching. * Tab ordering would be a good enhancement. * Only one launch delegate is selected to handle the launching. You can combine modes in any way you want - for exmaple 'debug & profile', or 'run, debug, profile & coverage'. It's just a set of modes - we look for a launcher that can handle it. * There is an existing extension point for launch modes - org.eclipse.debug.core.launchModes. You should define a 'coverage' mode. * Having particiapants for command line options is not generic enough for the platform. It might work for Java that uses a command line to launch, but launching in general may not use a command line - it's just one implementation of a launch. * We provide abstract launch delegates for Java, so subclassing and overtaking the launch should be easy. For launching Java apps, I can see where a launch particiapant to modiy a command line would be useful, so we might be able to enhance the java launch infrastructure to look for particiapants... so the steps would look like: * contribute a launch mode (if required) * contribute a launch tab * contribute a launch delegate for the mode combinations you support - but just specify the standard java launch delegate * at launch time, the standard java launch delegate looks for participants for the additional launch modes We might want to start a new "JDT enhancement request" for this support, as it just builds off this new platform support. Created attachment 52498 [details]
patch
this patch builds on the previous efforts by including:
1. added a new extension addition for the launchDelegate extension point, which allows lists of mode sets to be specified (as comma seperated lists)
2. treats all modes specified using either the new modesCombinations extension addition, or the traditional method (specifying a list of mode in the vconfig type or delegate declaration) as a set of modes.
3. updates existing code for launch actions etc to use the new supported mode sets, without changing existing APIs
Having explict supported mode combinations is good. Comments: * The ILaunchConfigurationType.getSupportedModes() API shouldn't be re-used to return a Set of <Set>, as it used to return a Set of <String> in 3.2. Although the method signature remains binary compatible, it would break clients, potentially causing class cast exceptions. * On the launchDelegates extension point, shouldn't the 'modesCombintation' be a 'modeCombinations' element, with an squence of elements as children (1 or more), of launch modes? It wasn't clear to me how one would specify more than one mode combination with the current schema. (Unless its a comma seperated list with space seperated lists within it?) *** Bug 127196 has been marked as a duplicate of this bug. *** Created attachment 52620 [details]
work in progress
this is a work in progress patch, it build upon the existing efforts providing the following:
1. duplicate delegate resolutions mechanisms, including a pref page and "on the fly" selection capabilities
2. no delegate found resolution mechanisms, with "on the fly" selection capabilites
3. new API for getting/setting preferred launch delegates
released latest changes to HEAD (including all previous changes from patches), as well as update unit tests for features and fixes for previous tests. Updated example source code in test plugin found at: http://www.eclipse.org/eclipse/debug/misc/launch_option_example.zip *** Bug 137057 has been marked as a duplicate of this bug. *** *** Bug 162551 has been marked as a duplicate of this bug. *** Hi... I have also just started looking at the new extension points and APIs. I am wondering if it make sense to allow clients to optionally contribute a tab based on the tooling selection from the user? Here's the use case that I am thinking about: The platform provides the basic Java launch delgate/tooling to launch Java in single mode. (debug, run, profile, etc.) Someone then comes in a provide an extension to launch debug and profile at the same time. (A new tooling?) He/She also provides a "profile" tab extenstion that is only valid for profile mode. The tab is contributed to the java tab group. If the user has selected this new tooling as the default launch delegate to launch when launching in debug mode, then it makes sense to show the new "profile" tab in the launch configuration dialog. However, if the user has selected to use the "Debug Only" launch delegate by default, then having this new "profile" tab visible in debug mode becomes distracting. Also, does it make sense to allow tab groups to be contributed to other tab groups? What if I have a tab group for profiling java application. I may want to contribute the entire group to another tab group when my mixed-mode tooling is selected? Another suggestion is to add an optional "description" field in the launch delegate extension point. Using just a name to describe what a launch delegate is responsible for may not be sufficient when trying to launch things in mixed mode. It maybe be useful to have a description field in the "Launch Tooling" preference page. Thanks... Samantha >Someone then comes in a provide an extension to launch debug and profile at >the same time. (A new tooling?) He/She also provides a "profile" tab >extenstion that is only valid for profile mode. The tab is contributed to the >java tab group. > >If the user has selected this new tooling as the default launch delegate to >launch when launching in debug mode, then it makes sense to show the new >"profile" tab in the launch configuration dialog. However, if the user has >selected to use the "Debug Only" launch delegate by default, then having this >new "profile" tab visible in debug mode becomes distracting. I guess the question is, how does the user generally "turn on" "debug & profile". We envision that the additional "profile" tab would have the option to turn on profiling. If we remove the tab because profiling is not on, then the user has to go to preference pages to access the function. We assumed the common use case would be to provid a mixed mode delegate (i.e. profile & debug), but would likely not override the "debug" mode when the user has turned the profiler option off. RE: contributing a group of tabs I think it makes sense to be able to contribute a multiple tabs at once, rather than contributing one tab at a time. For example, you might want to add three tabs to the the "Java Application" type to support profiling. Comments: 1. I think we should definately support filtering of tab contributions based what "tooling" the user has expressly selected. If no tooling is selected do we show all tabs and filter after, or show none and wait till the user selects some tooling? 2. Tab contributions should be filtered by contributions. i.e. if I have profile disabled in the contributions settings, I should not see a contributed tab that is applicable to profiling. This would work all the way down the resolving duplicate tooling (if I had duplicate tooling where one of the choices supported profiling, it would not be a viable choice/not available). 3. the notion of a description field for a launch delegate is good, it would help users to better select a delegate if they knew what they were for or did Rather than using a preference page to specify which launcher to use when there is more than one available, I think we could just re-use the hyperlink in the launch dialog. Currently, when you view a config that has more than one possible launcher, a link appears in the dialog allowing you to fix it (choose a launcher). We should show the link whenever there is more than one launcher, allowing the user to changed the "preferred delegate" - i.e. show the link for both error and non-error conditions. Created attachment 53657 [details]
newest patch
This patch is again a continuation of work in progress and builds on the current contributions with:
1. filtering of contributed launch tabs based on the preferred set of tooling
2. removed the 'icon' attribute for a launch config type
3. beefed up the explanations for modes and modeCombination attributes for launch delegate extensions
4. removed uneeded code from AbstractLaunchModeConfigurationTab and renamed class to AbstractLaunchConfigurationListenerTab
5. provided description attribute for launch delegates (appears on both the launchDelegate and launchConfigurationTypes extension points)
6. provided proxy access to the launch delegate descriptions, as well as presenting the description on the select launch tooling dialog
7. provided workbench activity filtering for contributed launch tabs
released patch to HEAD with minor changes * Reviewed extension point doc, with minor changes (points 2, 3, 5). * Removed AbstractLaunchConfigurationListenerTab. We believe the use of the class will be limited as many tab providers already have a type hierarchy of tabs and will not use this class (which only provides a simple 'listener adapter'). Interested parties: I think the remaining issue is what level of configurability we should support when there is more than one launcher for a config type/mode. For example, if both TPTP and YourKit provide profilers for Java Applications, then should we have a global workspace preference that enables one of them, or should there be a global default, but allow a configuration to override it? This would support the ability to have one configruation launch with TPTP and another with YourKit, for example. My initial feeling is that simply supporting the global workspace preference should be sufficient, but I'm not positive I know how people want this to work. I like the second option better than the first. It would be nice if the user would easily be able to use one of the registered delegates within the configuration. We could add a new tab to launch configuration tab groups that correspond to launch configuration types where possible ambiguities arise. This can be computed upfront based on the contributed extensions. This would also allow for the scenario of having multiple launch configurations to profile a project with different profilers, and the like. Based on the response so far, we plan to support workspace default launchers and allow configurations to override the default. The "Launch Tooling" preference page will be renamed to the "Default Launchers" preference page which will specify workspace default launchers for cases where there is more than one. The page will have description something like "These settings specify which launcher to use when multiple launchers are available for a configuration and launch mode." Two lists will follow with headers of "Launch Type/Mode:" and "Preferred Launcher". The preferred launcher list will be a check box list allowing the user to select the workspace default preferred launcher. The labels in the list of launchers will be based on a launch delegate's name attribute - and should be something like "Eclipse JDT", "YourKit Profiler", or "TPTP". When no name is specified by an launch delegate extension, we'll use the contributor name (plug-in name/id). When a configuration has more than one launcher available, a tab will be added to that configruation's tab group - called "Launchers". The tab will have similar controls to the "Default Launchers" preference page - i.e. lists labelled "Mode" and "Launcher" allowing the user to override workspace defaults. There will be a description on the top of the tab describing why the tab is there, something like - "More than one launcher is available for this configuration. Select the launcher to use." There should also be a check box specifying whether to "Use workspace default preferences". The check box should provide a hyperlink to the "Default Launchers" preference page. When no default launcher has been selected by a user, the first time a launch is performed, they will be prompted to choose a default launcher. released updates to HEAD: 1. pref page new naming and description field 2. duplicate delegates selection dialog updated 3. action selection dialog removed with improved story: press run with dupes and no default selected always prompt with chooser, cancel button cancels the launch 4. updated duplicate status handler 5. removed two prefs for prompting and for default prompt action Created attachment 54555 [details]
up to the minute....
This patch includes all previous enhancement requests including setting preferred launcher information for individual configurations.
major changes
1. can set preferred launchers on a per config basis, this is acheived via a 'properties' menu item in the launch viewer context menu
2. tab filtering has been updated and enhanced
3. launch dialog provides access to global scheme for preferred launchers
There are some drawbacks we have discovered.....
1. Setting the preferred launcher for a specific configuration can cause the ui to change (filtering of tabs). This could happen while they are in the middle of a lengthy edit, possible filtering a tab they made changes to
2. there needs to be a context to be able to set launcher information on a per config basis. This means we either need to include another tab or the like. which brings to light the problem above even more, especially in the case of providing a 'launchers' tab where working on one tab can cause others to disappear
3. updating the tab group everytime you make a selection in the launch viewer has added a very small delay between selections, but is necessary to perform filtering of UI elements in the dialog on a per config basis
4. It is not immediately obvious to the user that something can be changed (in terms of preferred launchers). It does not seem to make sense to us to set an error message indicating that there is/are more than one launcher to be used and they can change it if they want to. similarly it does not make sense to have a constant normal message on the dialog stating a similar thing
any thoughts would be greatly appreciated....
Created attachment 54562 [details]
updated patch
forgot to include one project :)
Created attachment 54584 [details]
further updated
This patch adds a link made available when there are multiple launchers for the following reasons
1. to give the user notice that there are settings that can be changed
2. to provide easy access to the features of the properties action from the launch view
Committed all previous mentioned changes to HEAD. more specificially the changes include: 1. all updates to the new API for extensible modes 2. the visible link for selection of preferred launchers 3. the dialog for selecting preferred delegates 4. help topics for the launcher selection dialog 5. update to recreating launch tabs, now tab groups are only recreated when either the types are different, or the types are the same but the preferred delegate for launching differs Released fix to show contributed tabs when a tab has no associated delegate (I don't think we can filter tabs that don't provide a delegateAssociation). Marking fixed. Will open new bugs as needed. Verified. |