Bug 310846 - [resolver][launch] Variable substitution framework doesn't take local behavior into account
Summary: [resolver][launch] Variable substitution framework doesn't take local behavio...
Status: CLOSED WONTFIX
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.6   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2010-04-28 11:37 EDT by Robert Konigsberg CLA
Modified: 2021-06-07 05:10 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Konigsberg CLA 2010-04-28 11:37:16 EDT
Build Identifier: I20090611-1540 

Here's an example of such a problem:

Consider the ${project_loc} variable, which optionally takes a variable. If the variable is missing, then it looks for a selection from either the selection service or the editors.

But let's talk about varaible resolution on the part of the launching framework. So, there you have a launch configuration that's typically associated with a project.*1

Suddenly ${project_loc} takes on a new meaning.

So let's say I have two projects, named Foo and Bar, and their locations are /path/foo and /path/bar.

So if I create a launch configuration (Heck, let's say a Java Application) and set the project to "Foo". Then we set the working directory to ${project_loc}. Save it. Don't launch it yet.

Now make sure no files are open in the editor. Then in the Project Explorer select '/Bar'.

Now launch the new launch configuration.

The working directory is /path/bar. What?? The launch configuration's project is Foo? Why shouldn't the working directory be /path/foo?

More to the point, what if I have started Eclipse, not selected anything, and tried launching that configuration? It won't be able to resolve ${project_loc} even though the launch configuration has a project.

Now, this very _specific_ example is not my genuine issue, because my specific issue is that I'm creating variable resolvers that are meant to provide project-specific metadata (I have a custom nature.) This same issue comes up.

*1 Granted, each launch configuration type can specify a project, so strictly speaking this isn't necessary.

Reproducible: Always
Comment 1 Darin Wright CLA 2010-04-28 11:46:06 EDT
This is a known issue, and other similar bugs have been reported in the past (for example, bug 170789). The existing variable resolution API does not support a "context" for resolution. The String variable substitution API would need to be enhanced to accept some sort of context when resoling variables in order to achieve this. 

I believe this should be marked as an enhancement request to support contexts for variable resolution.
Comment 2 Robert Konigsberg CLA 2010-04-28 11:50:08 EDT
Darin, thanks for the reply. Yeah I assumed it was a known issue, but it was hard for me to find an existing bug! So the reference to 170789 is helpful, thanks.

I'm going to probably work around this for now by doing some slightly ugly things (as opposed to moderately ugly things.) Since this is the debug component, I'll ask: can multiple launch configurations be launched in parallel? Or is there some sort of infrastructure lock or guarantee that only one ILaunchConfiguration.launch method is called at a time?
Comment 3 Darin Wright CLA 2010-04-28 17:09:44 EDT
(In reply to comment #2)
> Since this is the debug
> component, I'll ask: can multiple launch configurations be launched in
> parallel? Or is there some sort of infrastructure lock or guarantee that only
> one ILaunchConfiguration.launch method is called at a time?

There is nothing in the platform preventing this. It should be possible. (Of course, I'm not sure anyone has tried it...)
Comment 4 Eclipse Genie CLA 2019-06-15 17:10:05 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 5 Sarika Sinha CLA 2019-06-17 01:09:12 EDT
If someone wants to work on this we can look into it.
Comment 6 Eclipse Genie CLA 2021-06-07 05:10:26 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug.

If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.