| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><html lang="en"> |
| <HEAD> |
| |
| <meta name="copyright" content="Copyright (c) IBM Corporation and others 2000, 2013. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page." > |
| |
| <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> |
| <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css"> |
| |
| <LINK REL="STYLESHEET" HREF="../book.css" CHARSET="ISO-8859-1" TYPE="text/css"> |
| <TITLE>Plug-ins and fragments</TITLE> |
| |
| <link rel="stylesheet" type="text/css" HREF="../book.css"> |
| </HEAD> |
| <BODY BGCOLOR="#ffffff"> |
| <h2>Plug-ins and fragments</h2> |
| <p>Features are described in terms of the plug-ins that comprise them. A <strong>plug-in</strong> |
| is used to group your code into a modular, extendable and sharable unit.</p> |
| |
| <p>Plug-ins are <em>modular</em> as each plug-in contains some portion of code. The plug-in specifies |
| other plug-ins (or java packages) it requires to be available to run and it also specifies the set of |
| java packages it provides. An Eclipse based <a href="product.htm">product</a> will contain |
| multiple plug-ins, which can be added, replaced or removed to alter the functionality of the program.</p> |
| |
| <p>Eclipse plug-ins are based on OSGi bundles. OSGi is used to manage the plug-ins in a product. A |
| plug-in must contain a <a href="../reference/misc/bundle_manifest.html">manifest file</a> with valid |
| OSGi headers for plug-in name and version.</p> |
| |
| <p>Plug-ins are <em>extendable</em> using <a href="product_extension.htm">extensions and extension points</a>. |
| A plug-in can provide one or more extension points so other plug-ins can add to the functionality of |
| the plug-in. A plug-in may also provide extensions to connect to other plug-ins. To use extensions you must |
| provide a <a href="../reference/misc/plugin_manifest.html">plugin.xml</a> file.</p> |
| |
| <p>A <strong>fragment</strong> is used to replace or extend the functionality of |
| an existing plug-in. A common use for fragments is to put environment (operating system, |
| architecture, etc.) specific code into fragments. Depending on the environment the |
| plug-in is installed in the base plug-in code along with the correct fragment can be installed. |
| Fragments are also ideal for shipping features like language or maintenance packs that typically |
| trail the initial products for a few months.</p> |
| |
| <p>When a fragment is detected by the platform and its parent plug-in is found, |
| the fragment's libraries, extensions and extension points are "merged" with |
| those of the parent plug-in. While this merging mechanism is good from a runtime point of view, |
| developers need to view fragments as separate entities while working on them. Fragments require |
| a valid OSGi manifest. To use extensions and extension points they must define a fragment.xml |
| file which has the same structure as a plugin.xml file.</p> |
| |
| <p>Plug-ins and fragments can be packaged in <a href="../reference/misc/plugin_archive.html">Plug-in |
| archive</a> files</p> |
| |
| </BODY> |
| </HTML> |
