Difference between revisions of "FAQ What causes my plug-in to build but not to load in a runtime workbench?"

From Eclipsepedia

Jump to: navigation, search
 
(updated the information on troubleshooting runtime NoClassDefFoundErrors)
 
(One intermediate revision by one user not shown)
Line 1: Line 1:
Here is a typical scenario for a new user:
+
Runtime problems are usually indicated by a <code>java.lang.NoClassDefFoundError</code> when the plug-in is started.
You are writing a plug-in that extends plug-in XYZ. To get it to compile, you
+
add a reference to the JAR file for plug-in XYZ to your project&#146;s build path
+
either from the '''Java Build Path''' property page or by editing the <tt>.classpath</tt> file.
+
When you launch a runtime workbench, the following surprising error
+
is reported: '''java.lang.NoClassDefFoundError: XYZ.SomeClass'''.
+
Do not start looking in the '''Plug-ins and Fragments''' tab in the launch
+
configuration for the runtime workbench. That tab influences only which plug-ins are used
+
for your runtime workbench and whether they are loaded from the workspace or
+
from the Eclipse install directory.
+
  
 +
To troubleshoot runtime issues, it is helpful to understand a little bit more about Eclipse classpaths.
 +
Eclipse distinguishes between a compile-time classpath and a runtime classpath. The compile-time classpath provides the Eclipse development workbench with all necessary information for compiling a plug-in and is declared in the plug-in project's <code>.classpath</code> file. The runtime classpath, on the other hand, tells OSGi and the Eclipse runtime workbench which plug-ins and JARs are necessary to execute the plug-in. The runtime classpath is determined by the <code>MANIFEST.MF</code> file. Typically, the compile-time classpath includes most runtime dependencies, and the recommended way to incorporate these dependencies also at compile-time is to use the '''Plug-in Dependencies''' classpath container. This container will be automatically populated with the dependencies listed in the <code>MANIFEST.MF</code> file.
  
 +
<code>java.lang.NoClassDefFoundError</code>s are runtime problems, so editing the <code>.classpath</code> file will usually not solve these problems. Instead, check these files:
  
Instead, start looking in the plug-in manifest. Edit the <tt>plugin.xml</tt>  
+
* the <code>MANIFEST.MF</code> file
file and ensure that XYZ is mentioned as a required plug-in. Then, save
+
* the <code>build.properties</code> file
the <tt>plugin.xml</tt> file. This will update the project&#146;s build path
+
* the launch configuration that you used to start the plug-in
automatically.
+
  
 +
<br>
 +
In most cases, the <code>MANIFEST.MF</code> is the culprit. The most common problems with the manifest are:
  
 +
* missing "<code>.</code>" entry in the <code>Bundle-ClassPath</code>, especially when additional JARs were added to the plug-in's runtime classpath
 +
* missing <code>Export-Package</code> in the manifest of required plug-ins
  
Never manually edit the <tt>.classpath</tt> file  
+
<br>
when you are writing a plug-in. The plug-in Manifest Editor simply overwrites any
+
Next in line of the trouble-makers is the <code>build.properties</code> file. Most developers consider the <code>build.properties</code> file a compile-time file, because it mainly tells the PDE build how to package a deployable plug-in. However, the <code>build.properties</code> file is also used by PDE to create a runtime workbench that (as closely as possible) replicates the behavior that one would see if the packaged plug-in were to be deployed into a primary workbench. This "black magic" behind the scenes may preclude certain JARs or packages from being visible at runtime if the <code>build.properties</code> file is incorrect or incomplete. If you are 100% sure that your manifest is absolutely correct then you should check for warning markers in the <code>build.properties</code> file.
changes you make to it. Not very civilized, but that is the way it works.
+
 
+
 
+
  
 +
Finally, if your plug-in (or another plug-in that is required by your plug-in) is not enabled as part of your launch configuration its classes obviously cannot be loaded at runtime. If your launch configuration uses the "plug-ins selected below only" option, make sure that all required plug-ins are indeed selected in the list.
  
  
Line 37: Line 32:
  
 
[[FAQ_When_does_PDE_change_a_plug-in%26%23146%3Bs_Java_build_path%3F]]
 
[[FAQ_When_does_PDE_change_a_plug-in%26%23146%3Bs_Java_build_path%3F]]
 +
 +
<hr><font size=-2>This FAQ was originally published in [http://www.eclipsefaq.org Official Eclipse 3.0 FAQs]. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the [http://www.eclipse.org/legal/epl-v10.html Eclipse Public License v1.0].</font>

Latest revision as of 00:06, 18 February 2010

Runtime problems are usually indicated by a java.lang.NoClassDefFoundError when the plug-in is started.

To troubleshoot runtime issues, it is helpful to understand a little bit more about Eclipse classpaths. Eclipse distinguishes between a compile-time classpath and a runtime classpath. The compile-time classpath provides the Eclipse development workbench with all necessary information for compiling a plug-in and is declared in the plug-in project's .classpath file. The runtime classpath, on the other hand, tells OSGi and the Eclipse runtime workbench which plug-ins and JARs are necessary to execute the plug-in. The runtime classpath is determined by the MANIFEST.MF file. Typically, the compile-time classpath includes most runtime dependencies, and the recommended way to incorporate these dependencies also at compile-time is to use the Plug-in Dependencies classpath container. This container will be automatically populated with the dependencies listed in the MANIFEST.MF file.

java.lang.NoClassDefFoundErrors are runtime problems, so editing the .classpath file will usually not solve these problems. Instead, check these files:

  • the MANIFEST.MF file
  • the build.properties file
  • the launch configuration that you used to start the plug-in


In most cases, the MANIFEST.MF is the culprit. The most common problems with the manifest are:

  • missing "." entry in the Bundle-ClassPath, especially when additional JARs were added to the plug-in's runtime classpath
  • missing Export-Package in the manifest of required plug-ins


Next in line of the trouble-makers is the build.properties file. Most developers consider the build.properties file a compile-time file, because it mainly tells the PDE build how to package a deployable plug-in. However, the build.properties file is also used by PDE to create a runtime workbench that (as closely as possible) replicates the behavior that one would see if the packaged plug-in were to be deployed into a primary workbench. This "black magic" behind the scenes may preclude certain JARs or packages from being visible at runtime if the build.properties file is incorrect or incomplete. If you are 100% sure that your manifest is absolutely correct then you should check for warning markers in the build.properties file.

Finally, if your plug-in (or another plug-in that is required by your plug-in) is not enabled as part of your launch configuration its classes obviously cannot be loaded at runtime. If your launch configuration uses the "plug-ins selected below only" option, make sure that all required plug-ins are indeed selected in the list.


[edit] See Also:

FAQ_How_do_I_add_an_extra_library_to_my_project’s_classpath?


FAQ_My_runtime_workbench_runs,_but_my_plug-in_does_not_show._Why?


FAQ_When_does_PDE_change_a_plug-in’s_Java_build_path?


This FAQ was originally published in Official Eclipse 3.0 FAQs. Copyright 2004, Pearson Education, Inc. All rights reserved. This text is made available here under the terms of the Eclipse Public License v1.0.