All about Eclipse Plug-ins
- FAQ 94: What is a plug-in?
- FAQ 95: Do I use plugin or plug-in?
- FAQ 96: What is the plug-in manifest file (plugin.xml)?
- FAQ 97: How do I make my plug-in connect to other plug-ins?
- FAQ 98: What are extensions and extension points?
- FAQ 99: What is an extension point schema?
- FAQ 100: How do I find out more about a certain extension point?
- FAQ 101: When does a plug-in get started?
- FAQ 102: Where do plug-ins store their state?
- FAQ 103: How do I find out the install location of a plug-in?
- FAQ 104: What is the classpath of a plug-in?
- FAQ 105: How do I add a library to the classpath of a plug-in?
- FAQ 106: How can I share a JAR among various plug-ins?
- FAQ 107: How do I use the context class loader in Eclipse?
- FAQ 108: Why doesnt Eclipse play well with Xerces?
- FAQ 109: What is a plug-in fragment?
- FAQ 110: Can fragments be used to patch a plug-in?
- FAQ 111: What is a configuration?
- FAQ 112: How do I find out whether the Eclipse Platform is running?
- FAQ 113: Where does System.out and System.err output go?
- FAQ 114: How do I locate the owner plug-in from a given class?
- FAQ 115: How does OSGi and the new runtime affect me?
- FAQ 116: What is a dynamic plug-in?
- FAQ 117: How do I make my plug-in dynamic enabled?
- FAQ 118: How do I make my plug-in dynamic aware?
Part I discussed the Eclipse ecosystem: how to run it, how to use it, and how to extend it. In this chapter, we revisit the topic of plug-ins and lay the groundwork for all plug-in development topics to be discussed in later chapters. This chapter answers questions about the core concepts of the Eclipse kernel, including plug-ins, extension points, fragments, and more. All APIs mentioned in this chapter are found in the org.eclipse.core.runtime plug-in.
FAQ 94: What is a plug-in?
In retrospect, plug-in, perhaps wasn’t the most appropriate term for the components that build up an Eclipse application. The term implies the existence of a socket, a monolithic machine or grid that is being plugged into. In Eclipse, this isn’t the case. A plug-in connects with a universe of other plug-ins to form a running application. The best software analogy compares a plug-in to an object in object-oriented programming. A plug-in, like an object, is an encapsulation of behavior and/or data that interacts with other plug-ins to form a running program.
A better question in the context of Eclipse is, What isn’t a plug-in? A single Java source file, Main.java, is not part of a plug-in. This class is used only to find and invoke the plug-in responsible for starting up the Eclipse Platform. This class will typically in turn be invoked by a native executable, such as eclipse.exe on Windows, although this is just icing to hide the incantations required to find and launch a Java virtual machine. In short, just about everything in Eclipse is a plug-in.
More concretely, a plug-in minimally consists of a plug-in manifest file, plugin.xml. This manifest provides important details about the plug-in, such as its name, ID, and version number. The manifest may also tell the platform what Java code it supplies and what other plug-ins it requires, if any. Note that everything except the basic plug-in description is optional. A plug-in may provide code, or it may provide only documentation, resource bundles, or other data to be used by other plug-ins.
A plug-in that provides Java code may specify in the manifest a concrete subclass of org.eclipse.core.runtime.Plugin. This class consists mostly of convenience methods for accessing various platform utilities, and it may also implement startup and shutdown methods that define the lifecycle of the plug-in within the platform.
Note
FAQ 96 What is the plug-in manifest file (plugin.xml)?
FAQ 98 What are extensions and extension points?