View source for FAQ What is the classpath of a plug-in?

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:

*<i>The OSGi parent class loader</i>.  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 <tt>rt.jar</tt>, but the boot classpath can be augmented  with a command line argument to the VM.

*<i>The exported libraries of all imported plug-ins</i>.   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 <tt>plugin.xml</tt> file. 

*<i>The declared libraries of the plug-in and all its fragments</i>.  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 <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.



== See Also: ==
*[[FAQ What is the plug-in manifest file (plugin.xml)?]]
*[[FAQ How do I make my plug-in connect to other plug-ins?]]
*[[FAQ How do I add a library to the classpath of a plug-in?]]
*[[FAQ How can I share a JAR among various plug-ins?]]
*[[FAQ How do I use the context class loader in Eclipse?]]
*[[Pragmatic Advice on PDE Classpath]]

{{Template:FAQ_Tagline}}