Jump to: navigation, search

FAQ What causes my plug-in to build but not to load in a runtime workbench?

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.


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.