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

Bug 111177

Summary:

[UI] JARed plug-in with internal JARs requires . on Bundle-ClassPath in MANIFEST.MF

Product:

[Eclipse Project] PDE

Reporter:

Edward Sargisson <esarge>

Component:

Assignee:

PDE-UI-Inbox <pde-ui-inbox>

Status:

CLOSED WONTFIX

QA Contact:

Severity:

normal

Priority:

CC:

curtis.windatt.public, refsdal.ivar, stew

Version:

3.1

Keywords:

helpwanted

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

stalebug

Attachments:

Description	Flags
plugin that demonstrated incorrect calculation of workspace classpath	none

Description Edward Sargisson

2005-09-29 23:16:12 EDT

I am bulding a Log and Trace Analyzer plug-in which uses two additional JARs
which I want included in the JAR. In order for the plug-in to both run from the
Workbench and be buildable I needed to add . to the Bundle-ClassPath in MANIFEST.MF.

The "Shipping Your Plug-in As A single JAR" topic in the online help says that
the Bundle-Classpath [sic] header can simply be deleted. This appears to be
incorrect.

I needed to have my two JARs in the Bundle-ClassPath before I could compile or
use the Runtime workbench successfully. However, if they were the only two
entries then when I came to build my plug-in using the Export wizard the
compiled .class files would not be included.

If I removed the JARs from Bundle-ClassPath and added them to the
extra.jar.classpath in the build.properties file then I could build fine.
However I couldn't run the Runtime workbench because the necessary classes could
not be found.

By pure accident I tried adding . to the Bundle-ClassPath and now I can both
build and test my plug-in. This should be documented somewhere in the help.

However, I cannot use my plug-in outside the Runtime workbench as it cannot find
the GLA Adapter configuration file. I suggest that the help say that Log and
Trace Analyzer plug-ins cannot be single JARs for this reason.

Comment 1 Ivar Refsdal

2011-11-17 17:30:36 EST

Well this is obviously an old issue. Nevertheless it still happens.

The OSGi specification says that the default Bundle-Classpath is '.'.
If you specify Bundle-Classpath though, you also need to specify '.'.
However, things will still appear to build fine without the dot.

When you try to start the bundle though, an exception like this will happen:
osgi> start xxx
org.osgi.framework.BundleException: The activator xxx.yyy.zzz.Activator for bundle xxx.yyy.zzz is invalid

My suggestion is that Eclipse should detect and, like Equinox/OSGi, make this, i.e. the missing dot, an error and provide a quick fix assist for this.

Comment 2 Stewart Francis

2012-10-24 12:32:31 EDT

Created attachment 222732 [details]
plugin that demonstrated incorrect calculation of workspace classpath

Comment 3 Stewart Francis

2012-10-24 12:32:58 EDT

This issue still exists in Juno.  If I add a jar to the Bundle-Classpath (which forces me to specify a Bundle-Classpath, rather than let it default) and remove the ".", this action is ignored when computing the classpath in the workspace.  Any classes from the src folder can still be referenced, and packages can be exported.

When the project is exported as a binary plugin, the contents of the src folder don't even get compiled.  Worst case scenario: I export a bundle which references an activator that never got exported, which can never start.  This can all happen without being told at all.

Not including . on the Bundle-Classpath is totally valid of course, but the workspace classpath should take this into account.  Forcing recalculation of the classpath doesn't resolve the issue.

I've attached a sample source plugin that demonstrates this.

Comment 4 Curtis Windatt

2012-10-24 15:59:23 EDT

Moving to PDE UI as any warnings/quickfixes would belong to PDE UI.  Adding helpwanted keyword as I do not currently have time to work on this.

Comment 5 Eclipse Genie

2019-09-21 19:22:11 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.