This one really has me stumped.
Scenario:
- Windows 7 64-bit
- Lotus Notes (8.5.2)
- Eclipse Helios
- Java 6 Update 33 (64-bit) with JDK 7
- Installed JRE for the plugin project is set to use the JVM installed under Notes (that is,
C:\NotesDev\Notes\jvm). - Target Platform uses the installed JRE above, and imports the
framework\rcp\eclipseandframework\shared\eclipsesubfolders on the Locations tab. I can see that there are a total of 713 plugins available between the two folders. - The Run Configuration shows a total of 714 plugins selected (which includes the 713 from the Target Platform, and mine). I can see that this list includes both
org.eclipse.swt.win32.win32.x86_3.5.2.v34557f-RCP20100710-0200.jarandcom.ibm.rcp.swtex.win32_6.2.2.20100729-1241.jar.
The problem:
- If I do not explicitly include the two aforementioned JAR files in my build path, the application fails to compile (trying to import
org.eclipse.swt.widgets.Displayandcom.ibm.rcp.swt.swidgets.SToolItem). - If I include the aforementioned JAR files in the build path, the application compiles, but won’t run, due to a
NoClassDefFoundexception.
The questions:
- Why do I need to include these files in the first place? They are part of the workspace, and none of the other JAR files I’m referencing seem to need to be explicitly referenced.
- Why is this failing at run time? My understanding is that
NoClassDefFoundoccurs because the class was available at compile time, but isn’t at run time. But this is occurring on the same machine. (I’m trying to debug it locally, and I’ve even marked the JAR files for export!)
It seems to me that if the files are listed in the Runtime Configuration’s loaded plugins tab, I wouldn’t have to explicitly reference them. Am I incorrect regarding this? (Please be kind! I’m admittedly not an expert at this.)
Thanks in advance.
P.S. It’s worth noting that if I include the files in the build path, I can see that they are properly referenced in both MANIFEST.MF and the .CLASSPATH file.
MANIFEST.MF CONTENTS
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Plugin
Bundle-SymbolicName: com.satuit.crm.plugin;singleton:=true
Bundle-Version: 1.0.0.qualifier
Bundle-Activator: com.satuit.crm.plugin.Activator
Bundle-Vendor: Satuit Technologies, Inc.
Require-Bundle: org.eclipse.ui,
org.eclipse.core.runtime,
org.apache.axis,
org.eclipse.ui;bundle-version="3.4.2",
org.eclipse.core.runtime;bundle-version="3.4.0",
org.eclipse.ui.views;bundle-version="3.3.1",
com.ibm.rcp.jfaceex;bundle-version="6.2.2"
Bundle-RequiredExecutionEnvironment: JavaSE-1.6
Bundle-ActivationPolicy: lazy
Export-Package: com.satuit.crm.plugin,
com.satuit.crm.plugin.document,
com.satuit.crm.plugin.ui,
com.satuit.crm.webservice.agent
Bundle-ClassPath: .,
/NotesDev/Notes/framework/rcp/eclipse/plugins/org.eclipse.swt.win32.win32.x86_3.5.2.v3557f-RCP20100710-0200.jar,
/NotesDev/Notes/framework/rcp/eclipse/plugins/com.ibm.rcp.swtex.win32_6.2.2.20100729-1241.jar,
/NotesDev/lib/activation-1.1.1.jar,
/NotesDev/lib/mail.jar,
/NotesDev/lib/commons-lang3-3.1.jar,
/NotesDev/lib/SatuitCRM_XML_API2.jar
** .CLASSPATH CONTENTS **
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry exported="true" kind="con" path="org.eclipse.pde.core.requiredPlugins"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.eclipse.swt.win32.win32.x86_3.5.2.v3557f-RCP20100710-0200.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/com.ibm.rcp.swtex.win32_6.2.2.20100729-1241.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Workspace/lib/commons-lang3-3.1.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Workspace/lib/activation-1.1.1.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Workspace/lib/mail.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Workspace/lib/SatuitCRM_XML_API2.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.apache.axis_1.4.0.20100729-1241/axispatch.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.apache.axis_1.4.0.20100729-1241/axis.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.apache.axis_1.4.0.20100729-1241/jaxrpc.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.apache.axis_1.4.0.20100729-1241/saaj.jar"/>
<classpathentry exported="true" kind="lib" path="C:/NotesDev/Notes/framework/rcp/eclipse/plugins/org.apache.axis_1.4.0.20100729-1241/wsdl4j-1.5.1.jar"/>
<classpathentry kind="src" path="src"/>
<classpathentry kind="output" path="bin"/>
</classpath>
Well, as it turns out, the OSGI manifest will accept absolute paths on the classpath. Surprise, surprise.
Whether or not it should is another story. And what that will do to the application once it’s deployed is anyone’s guess. But the runtime and compile time errors have disappeared, and so far don’t appear to be resurfacing.
Once again, what we considered fact and actual fact turned out to be two very different things.