332112 – [patch] Missing source for Target Platform 'Installation' in runtime workbench

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

Bug 332112 - [patch] Missing source for Target Platform 'Installation' in runtime workbench

Summary: [patch] Missing source for Target Platform 'Installation' in runtime workbench

Status:	RESOLVED FIXED

Alias:	None

Product:	PDE
Classification:	Eclipse Project
Component:	UI (show other bugs)
Version:	3.7
Hardware:	PC Windows 7

Importance:	P3 normal (vote)
Target Milestone:	4.6 RC1
Assignee:	Markus Keller
QA Contact:

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2010-12-08 06:15 EST by Markus Keller
Modified:	2016-05-12 05:28 EDT (History)
CC List:	2 users (show)

See Also:	Gerrit Change Git Commit

Flags:	Vikas.Chandra: review+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Markus Keller

2010-12-08 06:15:33 EST

I20101207-2000

Missing source for Target Platform 'Installation' in runtime workbench

- new workspace
- import org.eclipse.ui.workbench from CVS
- launch a runtime workbench
- in the runtime, import org.eclipse.ui from CVS
=> 'Plug-in Dependencies' classpath container shows the bin folder of org.eclipse.ui.workbench

- in the runtime, add a new target platform, choose 'Installation', and select the I20101207-2000 install
- activate the new target
=> 'Plug-in Dependencies' classpath container shows the JAR for org.eclipse.ui.workbench
- open type org.eclipse.ui.internal.Workbench
=> Source not found

Works fine for classes that are not imported in the host workbench, e.g. org.eclipse.core.commands.AbstractHandler

Comment 1 Curtis Windatt

2010-12-08 09:34:52 EST

I'll need to go over your steps again to determine if this is a bug or if it is just target weaving.  When self hosting, the default target platform will use projects from the host workspace.

Comment 2 Curtis Windatt

2010-12-08 15:20:50 EST

I'm guessing that the source lookup is assuming that target weaving is taking place and pointing to an incorrect source location.  The source bundles are in the target and associated with their plug-ins correctly.

Comment 3 Eclipse Genie

2016-02-29 07:33:36 EST

New Gerrit change created: https://git.eclipse.org/r/67538

Comment 4 Markus Keller

2016-02-29 07:34:51 EST

The problem is that TargetWeaver#getWeavedSourceLibraryName(IPluginModelBase, String) wrongly assumes that the target platform always includes all bundles from the host, and then wrongly concludes that the source must be found in the host workspace.

Comment 5 Markus Keller

2016-02-29 09:34:09 EST

API Tools has a similar problem, see bug 488694. You can use those steps to reproduce this bug as well. At the end, e.g. type org.eclipse.core.runtime.content.BinarySignatureDescriber doesn't have a source attachment. This type is from the required bundle I20160223-0800/plugins/org.eclipse.core.contenttype_3.5.100.v20160120-1402.jar. TargetWeaver#getWeavedSourceLibraryName(..) wrongly applies the "bin" folder from the dev properties to this external bundle. The Gerrit fixes that.

Comment 6 Eclipse Genie

2016-05-09 06:38:33 EDT

Gerrit change https://git.eclipse.org/r/67538 was merged to [master].
Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=c5033c5a9fb4f03b184be2bcb67fc7ba358d2fb3

Comment 7 Vikas Chandra

2016-05-09 06:39:29 EDT

Thanks Markus !

Verified, tested and reviewed this one. Looks good for 4.6RC1

Comment 8 Vikas Chandra

2016-05-12 05:28:12 EDT

Markus,

can you verify this one?