Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "FAQ What causes my plug-in to build but not to load in a runtime workbench?"
(updated the information on troubleshooting runtime NoClassDefFoundErrors) |
|||
| Line 1: | Line 1: | ||
| − | + | Runtime problems are usually indicated by a <code>java.lang.NoClassDefFoundError</code> 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 <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: | ||
| − | + | * the <code>MANIFEST.MF</code> file | |
| − | file | + | * the <code>build.properties</code> file |
| − | the < | + | * the launch configuration that you used to start the plug-in |
| − | + | ||
| + | <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 | ||
| − | + | <br> | |
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| + | 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. | ||
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.MFfile - the
build.propertiesfile - 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 theBundle-ClassPath, especially when additional JARs were added to the plug-in's runtime classpath - missing
Export-Packagein 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%26%23146%3Bs_classpath%3F]]
FAQ_My_runtime_workbench_runs,_but_my_plug-in_does_not_show._Why?
[[FAQ_When_does_PDE_change_a_plug-in%26%23146%3Bs_Java_build_path%3F]]
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.