Community
Participate
Working Groups
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.
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.
Created attachment 222732 [details] plugin that demonstrated incorrect calculation of workspace classpath
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.
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.
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.
