Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "FAQ What is the classpath of a plug-in?"

(See Also:)
(See Also:)
 
(One intermediate revision by the same user not shown)
Line 9: Line 9:
 
In Eclipse 2.1, the libraries from the <tt>org.eclipse.core.boot</tt> and  <tt>org.eclipse.core.runtime</tt> were also automatically added to every plug-in&#146;s classpath.  This is not true in 3.0; you now need to declare the runtime plug-in in your manifest&#146;s <tt>requires</tt> section, as with any other plug-in.
 
In Eclipse 2.1, the libraries from the <tt>org.eclipse.core.boot</tt> and  <tt>org.eclipse.core.runtime</tt> were also automatically added to every plug-in&#146;s classpath.  This is not true in 3.0; you now need to declare the runtime plug-in in your manifest&#146;s <tt>requires</tt> section, as with any other plug-in.
  
== Pragmatic Advice ==
 
Here are some suggestions if you have '''plug-in''' code that compiles (classes found)
 
but fails at runtime with class not found.  There are at least three different classpaths:
 
# compile time
 
# runtime
 
# source code at debug
 
There are at least four different places these are controlled:
 
# MANIFEST.MF
 
# Preferences PDE Target Platform
 
# Project Right click Build Path Configure Build Path
 
# Launch Configuration.
 
Unless you know what you are doing, the first thing to do is make
 
sure that you only use MANIFEST.MF.  In particular the ''Configure Build Path'' has to be cleared out of anything you put in there because it is only seen at compile time.
 
 
In the MANIFEST.MF systematically try to use Dependencies->RequiredPlugins and
 
avoid Runtime->Classpath for anything
 
other than classes for your plugin. (The theoretical best solution is
 
to use "ImportedPackages" but its not clear to me what this thing does
 
in practice.)
 
 
If you still have trouble, go in to the source at the where you have the runtime problem
 
and "Open Declaration" on the method or field.  Then use the little double arrow
 
thingy on Package Explorer to sync the package view to the method.  That will tell you what lib/plugin is bound at compile time.  Then you need
 
to run the debugger to the line and figure out why that lib/plugin is not on the path.
 
  
  
Line 41: Line 17:
 
*[[FAQ How can I share a JAR among various plug-ins?]]
 
*[[FAQ How can I share a JAR among various plug-ins?]]
 
*[[FAQ How do I use the context class loader in Eclipse?]]
 
*[[FAQ How do I use the context class loader in Eclipse?]]
 +
*[[Pragmatic Advice on PDE Classpath]]
  
 
{{Template:FAQ_Tagline}}
 
{{Template:FAQ_Tagline}}

Latest revision as of 02:26, 30 January 2007

Developers coming from a more traditional Java programming environment are often confused by classpath issues in Eclipse. A typical Java application has a global namespace made up of the contents of the JARs on a single universal classpath. This classpath is typically specified either with a command line argument to the VM or by an operating system environment variable. In Eclipse, each plug-in has its own unique classpath. This classpath contains the following, in lookup order:

  • The OSGi parent class loader. All class loaders in OSGi have a common parent class loader. By default, this is set to be the Java boot class loader. The boot loader typically only knows about rt.jar, but the boot classpath can be augmented with a command line argument to the VM.
  • The exported libraries of all imported plug-ins. If imported plug-ins export their imports, you get access to their exported libraries, too. Plug-in libraries, imports, and exports are all specified in the plugin.xml file.
  • The declared libraries of the plug-in and all its fragments. Libraries are searched in the order they are specified in the manifest. Fragment libraries are added to the end of the classpath in an unspecified order.

In Eclipse 2.1, the libraries from the org.eclipse.core.boot and org.eclipse.core.runtime were also automatically added to every plug-in&#146;s classpath. This is not true in 3.0; you now need to declare the runtime plug-in in your manifest&#146;s requires section, as with any other plug-in.


See Also:


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.

Back to the top