Community
Participate
Working Groups
(1) Allow limiting of displayed launch configurations in the launch configuration dialog to the currently selected project only, I typically find it annoying to have all the myriad unittests of other projects mixed with those of the project i'm currently working on, with no distinctive differentiation in the tree view. [Will investigate, and possibly provide patch]. (2) Store launch configuration in .project or other file, this would make it easy to reproduce run / debug settings for shared projects. Maybe the information could be tagged for the its target platform, so that you could have one set for win32, and another for unix/linux. The only thing i see as a possible problem is the JRE definition, if users have added their own definitions.
Leon, have you explored using shared launch configurations? I believe this would address concern #2. Launch configurations can be specified as shared on the Common tab of the dialog. This allows you to control their location and sharing via the VCM. We look forward to your accessment of #1...do not hesitate to start a discussion on the debug mailing lists.
correct, #2 does exactly what i want. i don't know how i missed it, apologies :)
after some additional investigation, it seems that there isn't a quick solution for this, alas. the project attribute looks to be a JDT addition, while the content provider for the launch configuration tree resides in Debug UI, and shouldn't know about JDT attributes IMHO. i couldn't find a clear link between the configuration and the workspace project, for a workaround. a solution could be to make the project attribute more general, since i can't see when you'd have a launch configuration without associating a project with it? then the filtering could be done in org.eclipse.debug.internal.ui.launchConfigurations.LaunchConfigurationDialog as it is currently. comments?
Java remote launch configurations do not need to be associated with a project. Likely there are other cases for other languages.
Even in the local Java case, projects are merely a convenience and are not required. They exist simply to constrain the search for a main type and to provide default values for the source lookup fields. It is perfectly legal for a local Java application launch configuration to have no project specified.
I think the real goal here is the ability to define Working Sets of launch configs. This makes perfect sense as people launch different sets of configs when they're working in different contexts. If you're using Eclipse to work on different projects (and one of the core goals of Eclipse is to facilitate this), it seems that the current interface could quickly become oversaturated with configs that are useless in your current context. Short of adding the notion of Working Sets to the launch configuration framework, project-based filtering seems like it would be quite handy. While projects aren't required on launch configs, they would give the user a means for creating effective working sets (by assigning like configs to like projects) without an explicit Working Set infrastructure.
Sounds reasonable. I will implement this and see what kind of feedback it gets. Darin, OK to make this a 2.1 candidate?
I would prefer to see a (draft) API proposal, and description of how it would look to the user before implementing. There are no breaking API changes allowed in 2.1. The launch dialog has "high visibility", so changes need to be well integrated, as to not "break/change" the current usage.
A proposal has been posted to both debug mailing lists.
Popular opinion favors working sets instead of project filters. Will investigate.
As well, there is a request to filter by launch config type, or even a way to group launch config types. For example, we may have "java" config types - local, remote, JUnit, Runtime workbench. This may be out of scope for the current scheme, but should be considered if possible.
moving to a working set based approach has one minor implication: a working set of is not public (will it be shareable?), hence setting up the working set would be a manual process every time the project is newly created in the workspace (from CVS or some other source). this is admittedly a fringe case, working sets work for me :)
Implemented working sets for launch configurations. Actions to select/deselect a working set are accessed on tree context menu in launch configuration dialog. User may select individual configs, and/or entire config types. With the latter, all future configs of that type essentially become members of the working set. The working set in effect is persisted across invocations of the dialog & workbench.
Please verify, Darin W.
*** Bug 16325 has been marked as a duplicate of this bug. ***
Comments/Questions (1) Would it be beneficial to change the title of the "Launch Configurations:" tree? When all launch configs are showing, the title could be something like "All Launch Configurations:". When a working set is applied, we can use the name of the working set. This quickly indicates when a working set is being used, and which one. (2) The menu item labels for "Select working set..." and "Delselect working set" might be called "Show Working Set..." and "Show All". (Or, at least the capitalization needs to be modified).
I like (1) and will make this change. As for (2), I copied the wording (though not the capitalization unfortunately) from the Package Explorer. Are you alright with just making the capitalization match? I think this is a little more explicit than "Show All", since it's not clear this has anything to do with working sets.
Wording is fine for #2, since it is consistent with Java Tooling (with capitalization fix).
Made both fixes. On (1), I decided to follow the Package Explorer example and indicate the current working set via a tooltip on the tree label. This was necessary because we needed to maintain the mnemonic to give focus to the tree. The only other option was to add a second line of labels, which wastes a lot of real-estate.
Verified
Can someone explain (or show with screen capture) how to access this functionality? I'm looking at both 2.1.3 and 3.0M9 in the Launch Config dialog, but no matter where I right-click in the tree I don't see any working set choices. All I get are New, Duplicate, and Delete. I can find no mention of this in the 2.1.3 or 3.0M9 help pages, which should be fixed as part of this bug or entered as a new one?
This feature was removed - it never shipped.
