- 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?
This chapter is from the book
This chapter is from the book
This chapter is from the book
FAQ 97: How do I make my plug-in connect to other plug-ins?
Like members of a community, plug-ins do not generally live in isolation. Most plug-ins make use of services provided by other plug-ins, and many, in turn, offer services that other plug-ins can consume. Some groups of plug-ins are tightly related, such as the group of plug-ins providing Java development tools—the JDT plug-ins—and other plug-ins, such as SWT, stand-alone without any awareness of the plug-ins around them. Plug-ins can also expose a means for other plug-ins to customize the functionality they offer, just as a handheld drill has an opening that allows you to insert other attachments such as screwdrivers and sanders. When designing a plug-in, you need to think about what specific plug-ins or services it will need, what it will expose to others, and in what ways it wants to allow itself to be customized by others.
To rephrase all this in Eclipse terminology, plug-ins define their interactions with other plug-ins in a number of ways. First, a plug-in can specify what other plug-ins it requires, those that it absolutely cannot live without. A UI plug-in will probably require the SWT plug-in, and a Java development tool will usually require one or more of the JDT plug-ins. Plug-in requirements are specified in the plug-in manifest file (plugin.xml). The following example shows a plug-in that requires only the JFace and SWT plug-ins:
<requires> <import plugin="org.eclipse.jface"/> <import plugin="org.eclipse.swt"/> </requires>
Your plug-in can reference only the classes and interfaces of plug-ins it requires. Attempts to reference classes in other plug-ins will fail.
Conversely, a plug-in can choose which classes and interfaces it wants to expose to other plug-ins. Your plug-in manifest must declare what libraries (JARs) it provides and, optionally, what classes it wants other plug-ins to be able to reference. This example declares a single JAR file and exposes classes only in packages starting with the prefix com.xyz.*:
<runtime>
<library name="sample.jar">
<export name="com.xyz.*"/>
</library>
</runtime>
Finally, a plug-in manifest can specify ways that it can be customized (extension points) and ways that it customizes the behavior of other plug-ins (extensions).
Note
FAQ 96 What is the plug-in manifest file (plugin.xml)?
FAQ 98 What are extensions and extension points?
FAQ 104 What is the classpath of a plug-in?