Bugzilla – Full Text Bug Listing
| Summary: | [launching] add a launch_name variable for launch configurations | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Rafael Chaves <eclipse> |
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | dj.houghton, wassim.melhem |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Rafael Chaves
Just hit by this again. Wanted to run two instances of a runtime workbench at the same time (had launched one already). I just copied the launch configuration, remembered changing the workspace location to something else but forgot to do the same for the configuration area. The existing instance started to fail (the configuration area was being deleted by the second instance) and they both started to fail. If this feture was supported, I would not have to remember anything and things would just work. Should the variable resolve to the name of the launch configuration? yes. that would be suitable for the pde scenario. Unfortunately, this reveals a limitation (design point) of the "dynamic" variable support. The variables are used to support string substitution. To allow any client to use/resolve all variables in an expression, an expression is resolved using the expression alone (i.e. no extra context such as the current launch configuration, as clients defining variables do not know about eachother and what context(s) to pass into a string substitution). To get arround this issue, we allow variables to have arguments. So, for example, the "system property" variable accepts the name of a system property. The property is resolved in the Eclipse runtime. However, in this case an argument to the "launch_name" variable is unhelpful (as it would have to contain the name of the config, which can change). Can PDE solve this in another way? If all you want is a common prefix, perhaps that should be a seperate field/attribute of the config? We can't support this with the existing string substitution support. See similar problem with bug 119582. Not planned for 3.2 *** Bug 132174 has been marked as a duplicate of this bug. *** *** Bug 208266 has been marked as a duplicate of this bug. *** As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. |