Community
Participate
Working Groups
The launching platform does not provide a way to group launch configuration types. There is no way to specify "These 10 config types belong to Provider A's tool and these 5 belong to Provider B's tool." This is a problem for a number of reasons: 1. The number of launch config types quickly becomes too large to quickly navigate. We've seen plugins that provide a dozen launch config types. We're going to see more. If we allow the user to view only launch config types in a particular group, the list becomes much more managable. 2. The namespace for launch config types is too small. As an example, the Eclipse SDK provides a "Remote Java Application" launch config type and someone else provides a "Connect to Running Process" launch config type. When the user wants to debug a remote application, they have no clue which type they should select. Launch config type grouping would provide the necessary context for similarly named types, allowing the user to do the right thing. What we have today: Connect to Running Process Connect to Running Server Debug a Compiled Application Debug Running Server E-Business Server Java Application Java Bean Java Program Java Test JUnit Test Remote Java Application Web Server What grouping would give us: Eclipse JDT -- Java Application -- JUnit Test -- Remote Java Application My Web Tooling -- Connect to Running Process -- Connect to Running Server -- Debug a Compiled Application -- E-business Server -- Web Server My J2EE Tooling -- Java Bean -- Java Program -- Java Test
The ideal solution to this problem would probably require an API change. That's not possible for the 2.1 stream, but I believe we could circumvent the API issue by providing the functionality on the launch configuration manager (or some other publicly accessible, non-implemented utility point). We could allow 3rd parties to register launch configuration groupings with us optionally.
In additoion, we will be shipping about 4 iSeries launch configuration types. This will add another group to the list below.
I propose creating a "Launch Configuration Type Group" extension point and adding an optional key/value pair to the launch configuration type extension point to specify which group a configuration type belongs to. Configuration types that did not specify a group could be grouped under one heading ("Other," "Misc.", or what have you) in the dialog.
Marking as later until 2.1 feature set is determined.
Open for 3.0 investigation.
*** Bug 24125 has been marked as a duplicate of this bug. ***
*** Bug 35403 has been marked as a duplicate of this bug. ***
*** Bug 45773 has been marked as a duplicate of this bug. ***
Jared, I beleive this problem will be solved with the workbench activity configuration?
No, I don't think it does. Even if the Eclipse SDK played the activities game (and it sounds like we're not planning to), the user can still enable multiple activities that provide launch configs which "conflict" with each other.
Nothing else planned for 3.0. We have activity filtering support, for which the SDK will provide activity definitions. Can investigate further support post 3.0.
*** Bug 58079 has been marked as a duplicate of this bug. ***
open for 3.1
Should look at ways to further group configuration types withing the launch dialog. Options: * Capabilities * Client defined categories
* Should also consider that use of launch shortcuts can create many launch configurations that the user may never want to edit. We might want to consider a scheme whereby configs created via shortcuts do not appear in the dialog (or perhaps only the last one does), but they still appear in the launch history. * May want to consider providing support to map from a resource to its associated configurations. This would allow a user to see all the configurations associated with a project or file.
Deferred.
Closing. There are various improvemens in 3.3 and 3.4 - filters for specific launch config types, deleted projects, closed project, etc. New bugs should be opened for specific issues as required.
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
