0

I'm developing a plug-in that needs access to the class org.eclipse.swt.widgets.Display. This class is contained in org.eclipse.swt.win32.win32.x86_3.5.2.v3557f-RCP20100710-0200.jar. However, the class is also exported by the manifest in com.ibm.rcp.jfaceex_6.2.2.20100729-1241 as follows:

Export-Package: com.ibm.rcp.jface.action,com.ibm.rcp.jface.launcher,co
 m.ibm.rcp.jface.themes,com.ibm.rcp.jface.util,com.ibm.rcp.jface.viewe
 rs,com.ibm.rcp.jface.window,com.ibm.rcp.jface.window.effects,com.ibm.
 rcp.ui.widgets.api.jface,com.ibm.rcp.ui.widgets.api.swt
Require-Bundle: com.ibm.rcp.swtex,org.eclipse.swt,org.eclipse.core.run
 time,org.eclipse.jface,org.eclipse.ui

Now, com.ibm.rcp.jfaceex is not included as part of my JRE System Library. It is, however, a bundle that includes classes of its own, as well as the exported packages above.

I was led to beleve that all I needed to do in my own project was to include a reference to it in my own project's build path, but this does not appear to work. The compiler is unable to resolve import statements against the classes in the org.eclipse.swt.widgets package.

If I need those classes, what, exactly do I need to do to import them correctly, and with the least amount of work?

Note We are not using Maven or any third party build tools. This is mandated by management, and I cannot change it.

UPDATE

Per the suggestion of E-Riz, below, I added org.eclipse.swt to the Required Bundles section of the Dependencies tab of my plug-in. Then, I attempt to export the project as follows:

  1. Right click project, select Export.
  2. Select Plug-in Development -> Deployable plug-ins and fragments
  3. Select All, then click Finish

Eclipse builds the project, then tells me there were errors. Examination of the log reveals the following error:

1. ERROR in E:\NotesDev\Plug-in\com.ibm.lotuslabs.ui\src\com\ibm\lotuslabs\ui\UI.java (at line 1)
    /**
    ^
The type org.eclipse.swt.widgets.Shell cannot be resolved. It is indirectly referenced from required .class files

There are dozens of these throughtout my code; one for every reference to a class or method in the org.eclipse.swt namespace bundle. This, despite the fact that the bundle debugs just fine!

UPDATE 2

I've discovered that you can, in fact, put absolute paths into the Bundle-Classpath in MANIFEST.MF. Oddly, this made the compile-time errors vanish. I am not convinced at this point that this is the correct thing to do, since absolute paths are certainly not guaranteed to correspond to the end-user's configuration.

However, installing the plug-in into Notes (the target platform), is not working as intended.

Notes reports that the plug-in installed successfully, but the plugin (an addition to the toolbar) does not appear. I am assuming, at this point, that something with the classpaths still isn't right.

UPDATE 3

Per request, the MANIFEST.MF and build.properties files. Please note that absolute paths were added by Eclipse, through the Dependencies and Runtime tabs.

MANIFEST.MF:

Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Context Plug-in
Bundle-SymbolicName: com.ibm.lotuslabs.context.service;singleton:=true
Bundle-Version: 1.0.2
Bundle-Vendor: IBM
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-Activator: com.ibm.lotuslabs.context.service.internal.ContextPlugin
Bundle-ActivationPolicy: lazy
Bundle-ClassPath: context.jar,
 lib/activation-1.1.1.jar,
 lib/mail.jar,
 lib/SatuitCRM_XML_API2.jar,
 lib/commons-lang3-3.1/commons-lang3-3.1.jar,
 E:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.eclipse.swt.win32.win32.x86_3.5.2.v3557f-RCP20100710-0200.jar
Require-Bundle: org.eclipse.core.runtime,
 org.eclipse.ui,
 org.eclipse.ui.views,
 org.eclipse.swt,
 com.ibm.rcp.swtex,
 com.ibm.rcp.jfaceex,
 com.satuit.core 
Export-Package: com.ibm.lotuslabs.context.service.document,
 com.ibm.lotuslabs.context.service.internal
Import-Package: org.eclipse.core.resources

build.properties:

output.. = bin/
bin.includes = META-INF/,\
               context.jar,\
               lib/activation-1.1.1.jar,\
               lib/mail.jar,\
               lib/commons-lang3-3.1.jar,\
               lib/SatuitCRM_XML_API2.jar,\
               plugin.xml,\
               E:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.eclipse.swt.win32.win32.x86_3.5.2.v3557f-RCP20100710-0200.jar
jars.compile.order = context.jar
source.context.jar = src/
Mike Hofer
  • 16,477
  • 11
  • 74
  • 110
  • How about compiling result of your plug-ins inside Eclipse PDE? Are they successfully compiled by Eclipse? – Kane Jul 11 '12 at 15:54
  • No. The update above shows what happens after adding the fix. It's all very peculiar. Any modifications I make through Eclipse result in either being unable to debug the application due to a classpath error, or being able to debug it but being unable to export it due to a classpath error. – Mike Hofer Jul 11 '12 at 16:56
  • @Kane, I may have misunderstood your question. The code compiles just fine within PDE (I can clean and it builds just fine). I cannot, however, export it to a JAR without errors. – Mike Hofer Jul 11 '12 at 16:58
  • Not sure what's the problem. You can use latest Eclipse Juno to have a try. – Kane Jul 12 '12 at 03:20
  • @Kane, I tried doing so in Juno with fairly disastrous results, lol. Juno wouldn't even *launch* Notes (my plug-in host). – Mike Hofer Jul 12 '12 at 13:58
  • Definitely you incorrectly set your target platform to fail launch Notes. Juno just is IDE, it should not involve into runtime of your Notes running. – Kane Jul 13 '12 at 03:11
  • You should remove absolute reference of swt from your MANIFEST, build.properties and project build path. – Kane Jul 13 '12 at 03:12
  • @Kane, interestingly enough, those absolute paths were added by Eclipse. Further, when they were added, the runtime and compile-time errors went away. Upon inspection, the absolute paths appear on the Runtime tab in the Classpath section with the message that they specify paths that are not required to exist *at runtime.* – Mike Hofer Jul 13 '12 at 13:28

3 Answers3

3

Just because a bundle names a package in its Export-Package declaration does not necessarily mean that it contains the code for that package. A bundle can export packages from bundles that it depends on (although I think that's generally a bad idea in most cases).

For you, the solution is simple: in your MANIFEST.MF go to the Dependendencies tab and add org.eclipse.swt to the list of Required Plug-ins

E-Riz
  • 31,431
  • 9
  • 97
  • 134
  • I tried that. Unfortunately, this produces errors when I attempt to export the bundle to a JAR file. Specifically, any types in org.eclipse.swt.widgets cannot be resolved. – Mike Hofer Jul 06 '12 at 17:11
2

Not quite sure, but two things come to mind.

  • Either remove the jar from your project classpath and add the com.ibm.rcp.jfaceex jar to your target platform (Preferences->PDE->Target platform and point to a directory containing the com.ibm.rcp.jfaceex jar)

  • Or leave the reference and also add the jar to your bundle classpath (on the runtime tab of the MANIFEST)

It don't quite see how this would result in this error, but classpath problems can manifest themselves in weird ways in PDE.

Frank Lee
  • 2,728
  • 19
  • 30
  • The odd thing is that `com.ibm.rcp.jfaceex.jar` is already included in the target platform. I can see it when I go to *Preferences->Plug-in Development->Edit* and check the *Show Location Content* checkbox. – Mike Hofer Jul 12 '12 at 13:53
  • Also, if I add the jar to the bundle classpath, Eclipse Helios puts it in there with an absolute classpath, which (as I understand it) is undesirable, as it likely won't match the end-user's configuration. – Mike Hofer Jul 12 '12 at 13:55
  • Can you post your manifest.mf and build.properties files here or is is sensitive? There *must* be something there. – Frank Lee Jul 12 '12 at 14:13
  • Sure, I can do that. I have another question for you. If a JAR file is already in the target platform, why would Eclipse generate errors telling me that it is not on the Build Path? I would assume that it doesn't need to be on the build path if it's in the target platform. – Mike Hofer Jul 12 '12 at 14:18
  • That *is* odd, I don't think you should have it on two locations. What is the exact error? I'd expect more a 'dependency can not be resolved' kind of error. – Frank Lee Jul 13 '12 at 08:21
0

I have taken a look at the swt related bundles in eclipse juno: org.eclipse.swt_3.100.0.v4233d.jar org.eclipse.swt.win32.win32.x86_3.100.0.v4233d.jar

The widgets are in the second bundle which is a fragment to the first.

So you have to make sure both bundles are in the target platform. I am not sure if require bundle works in that case (it may work). You may try to instead import all packages you need. Especially you need Import-Package on the package org.eclipse.swt.widgets.

Christian Schneider
  • 19,420
  • 2
  • 39
  • 64