Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 24793

Summary: Runtime launch config & source lookup
Product: [Eclipse Project] PDE Reporter: Darin Wright <darin.eclipse>
Component: UIAssignee: Wassim Melhem <wassim.melhem>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P2 CC: Darin_Swanson, jed.anderson, knut_radloff, veronika_irvine
Version: 2.0   
Target Milestone: 2.1 M5   
Hardware: PC   
OS: Windows 2000   
Whiteboard:
Attachments:
Description Flags
Contribution for source lookup path support none

Description Darin Wright CLA 2002-10-15 12:04:42 EDT
Currently, the way the runtime workbench launch configuration creates a source 
locator is problematic:

* the source locator is created using API which specifies the projects to be 
included in the source lookup. This does not account for a non-workspace JRE 
being used to debug. For example, if I build my plug-ins with ibm1.3.1, but 
debug on jdk1.4.1, I see the ibm1.3.1 source at debug time. This is supported 
with regular Java applications.
* the Java UI source locator prompts the user for soure when source is not 
found. However, the prompt assumes that the underlying launch cofiguration uses 
the Java launch configuration source lookup attributes to define its current 
and future source lookup paths. Thus the dialog opens with the incorrect set of 
projects, and changing the source lookup path does not effect future launches 
(@see IJavaLaunchConfigurationConstants - ATTR_SOURCE_PATH, 
ATTR_DEFAULT_SOURCE_PATH).

By default, a Java application computes the source lookup path to be the same 
as the build path, with the runtime JRE substituted for the development time 
JRE.
Comment 1 Dejan Glozic CLA 2002-10-16 11:06:51 EDT
Please suggest the possible changes in PDE launcher to achieve the desired 
effect - we are not sure we understand the issues clearly to be able to do it 
ourselves.
Comment 2 Darin Wright CLA 2003-01-10 13:48:25 EST
See bug 29225. There is an additional problem in that pressing "OK" to dismiss 
the source lookup dialog causes the source lookup path in the source locator to 
be incomplete for the rest of the debug session.
Comment 3 Darin Wright CLA 2003-01-23 13:02:47 EST
*** Bug 27263 has been marked as a duplicate of this bug. ***
Comment 4 Jed Anderson CLA 2003-01-23 14:39:43 EST
I suggest we mark this bug as critical since 27263 was marked critical and
because it makes one style of selfhosting impossible (i.e. selfhosting without
importing the plugins).

If there are no protests, I will futher investigate a fix for this bug.  I have
seen how it manifests itself by working with Joe.
Comment 5 Wassim Melhem CLA 2003-01-23 14:51:51 EST
The PDE team is planning to address all major launcher issues (i.e. source code 
lookups, etc) for M5.  The reason why this one has not been addressed yet after 
all this time is because Darin's original description of the bug is worded in a 
language that can only be understood by Debug team members, and the 
clarification that we had requested was not provided.
Comment 6 Darin Wright CLA 2003-01-24 09:21:44 EST
OK, I am late on this one. I did not realize the original description was 
unclear.

The problem is this: The PDE launcher sets up a source locator, which is an 
instance of the JavaUISourceLocator. When source cannot be found for a stack 
frame, this source locator prompts the user to find source. This source locator 
assumes certain attributes are present on the underlying launch config - 
attributes which define the source lookup path being used. PDE does not use 
these attributes, and thus, when prompted to find source, the dialog does not 
display the proper source lookup path that is being used (it displays only the 
class libraries, since that is all it can infer from the launch config). Worse, 
when the user presses OK, the associated source locator is changed to use the 
source locations listed in the dialog (which is obviously incomplete). Thus, as 
the user continues to debug, they are now severely handicapped, since their 
source lookup path only contains system libraries. [The dialog also updates the 
launch config with the new source lookup path attributes, but since PDE does 
not use these attributes, subsequent re-launches begin with the proper source 
lookup path again.]
Comment 7 Darin Wright CLA 2003-01-24 09:26:35 EST
I'm looking at the PDE code to determine the best/simplest solution.
Comment 8 Wassim Melhem CLA 2003-01-24 12:38:47 EST
*** Bug 18603 has been marked as a duplicate of this bug. ***
Comment 9 Darin Wright CLA 2003-01-24 22:37:29 EST
Created attachment 3144 [details]
Contribution for source lookup path support

Attached is a zip file containing three source files (two changed, once new),
and a changed "plugin.xml" file. This is a contribution that adds a source
lookup tab to the Runtime Workbench launch config tab group (the same as the
source lookup tab on java launch configs).

Overview:
* I have defined a "source path provider", as an extesnion point -
WorkbenchSourcePathProvider. A source path provider is responsible for
computing an unresolved source lookup path for a launch config, and is
responsible for resolving the source lookup path at runtime to specific source
locations
* An unresolved source lookup path contains entries such as projects, classpath
containers, etc. This is the path that is displayed and manipulated in the UI.
* A resolved source lookup path resolves contains the corresponding archives,
source folders, etc.
* There is a new extension point definition in the plug-in xml for this
* I have added the "source lookup tab" to the workbench tab group
* The delegate has been changed to only construct a source locator if the
configuration being launched does not have a source locator associated with it
(which will run the same as the old previous implementation)
* Newly created configs & configs that are re-opened in the LCD will be
updated, and tagged as ATTR_SOURCE_LOCATOR_ID = "Java UI Source Locator".
* The source locator will be constructed by the launching framework via this ID


Give it a whirl. I have tried it with the latest PDE code from HEAD and it
seems to play well.
Comment 10 Wassim Melhem CLA 2003-01-26 13:49:32 EST
Fixed by applying Darin's suggested changes.