Community
Participate
Working Groups
Currently source lookup interfaces, most notably ISourceLookupDirector are pretty closely tied to launches and launch configurations. The links between the to include: 1) Serializing of launch data a) IPersistableSourceLocator.initializeFromMemento() takes a launch configuration as an argument. b) AbstractSourceLookupDirector listens to launch configuration changes and automatically updates itself when the config changes. c) The default UI: SourceLookupPanel reads and write source lookup data to a launch configuration. 2) Configuration and access to the source lookup object d) launch configuration extension point takes a single source locator ID and source patch computer in its configuration. d) ILaunch.getSourceLookup() is the only API method to retrieve a source locator from the launch object. The problem with this linking is that it limits somewhat how the source lookup infrastructure can be used (or at least used easily). Example problematic use cases are: I) Launching a debug session with multiple processes/cores with a single launch - Ideally here, each process/core would have its own source lookup settings. II) Using source lookup with other tools such as profilers that do not integrate easily with the launch framework. I don't have any design proposals at this point, I just wanted to create a starting point for discussion.
(In reply to comment #0) > I) Launching a debug session with multiple processes/cores with a single launch > - Ideally here, each process/core would have its own source lookup settings. To support this scenarion I had to create a delegating source lookup director to dispatch lookup querries to the right directors. But this approach requires new UI.
future
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.
