L0016 - The Structure of an Eclipse Plug-in

Editor's Notes

• #2: \n
• #3: The configuration/config.ini file contains the very basic information needed to launch the product. This includes\nA list of all the plug-ins that should be load at start up.\nThe name of the product to start.\nThe file name of the splash screen to show while the product is started, if any.\nThe plug-ins that makes up an Eclipse RCP application can be divided into three basic groups:\nThe basic Eclipse RCP plug-ins such as org.eclipse.core.runtime and org.eclipse.swt.\n3rd party plug-ins such as BIRT, EMF but also org.eclipse.update.core.\nThe plug-ins with the functionality of the application.\nThe RCP runtime (and OSGi) does not distinguish between the different types of plug-ins. The format of plug-ins are described in the module “L0016 - The Structure of an Eclipse plug-in”.\nThe file system will only include features if the product is feature-based. And unless the product uses the update manager, there is no reason to use features.\n
• #4: A fragment is recognized in the MANIFEST.MF file by the presence of the Fragment-Host specification.\n
• #5: In the above example we see the junit plug-in directory. The junit plug-in is available after downloading and installing Eclipse. Every plug-in directory has archive and manifest files. In the above example there are two additional files:\nabout.html - that contains detailed textual description about plug-in\nplugin.properties - file that contains localized strings from plugin.xml\nPlease note that most plug-ins are distributed as .jar files where the above files are embedded with the exception of the .jar file.\nOSGi is able to handle plug-in jar files that in turn contain other jar files. This situation can occur when a 3rd party jar file is needed in an application, but for various reasons it cannot be repackaged – e.g. due to licensing restrictions or a digital signing on the original jar file. When PDE must handle embedded jar files it simply retrieve the files when the bundle is started and then rearranges the class path to include the new locations. This, though, is expensive both in terms of execution time and disk-space and should therefore normally be avoided, if possible.\n
• #6: Most of these files can exist both in a jar based plug-in (a plug-in packaged as a single .jar file) and in a directory based plug-in. As long as the files from a plug-in are accessed using FileLocator.find(Bundle, IPath, Map) this is completely transparent.\nMore information:\nMANIFEST.MF: http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/reference/misc/bundle_manifest.html\nabout.ini:\nhttp://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/reference/misc/about_customization.html\nSee the module “L0054 - Localization of an Eclipse RCP Application” for information on exactly what can be localized\n
• #7: \n
• #8: The declaration files for extension points are based on a restricted form of XSD (as also implied by the extension).\n
• #9: The complete syntax for the manifest file is found in “OSGi Specifications”. The Eclipse-specific headers are described in “OSGi Bundle Manifest Headers”.\n
• #10: The plugin.xml file is a regular XML file. The schema for the XML is made up of the schemas for all possible extension points. The syntax is checked in the plugin.xml editor, but not when the plug-in is resolved.\nBefore Eclipse 3.0, the plugin.xml file also included the information that is now put in the MANIFEST.MF.\nThe plugin.xml file shown above defines a new global menu with an action (3.2 edition).\n
• #11: \n
• #12: The  PDE has a number of multi-page editors, including the plug-in manifest editor, that share the same basic behavior. The editor has one or more source pages that show the raw file content and one or more form pages that present the same information in a more structured format. \nThe plug-in manifest editor partitions the form information into several pages for less clutter. The best way to learn about the plug-in manifest editor is to visit each page.\n
• #13: The Dependencies page shows the dependencies that your plug-in has on other plug-ins.  The plug-ins your plug-in currently depends on are shown in the list. You can modify the list by adding more plug-ins (button Add...) or removing them from the list. Changes in this list will prompt PDE to update the plug-in manifest and also configure the build path of the project so that the classes of the imported plug-in are visible to the plug-in under development.\nOnce you add the plug-in reference to the list, you can browse it by selecting Open from the pop-up menu or double-clicking on the entry.\nUse the “Automated Management of Dependencies” sub-page to add all the possible plug-in dependencies to your project:\nContent assist will include all Java classes from these classes as well as all classes from required plug-ins\nThe required plug-ins will automatically be updated\n
• #14: The Runtime page describes which Java packages of the plug-in may be exported to other dependent plug-ins. Only the listed packages can be used by other plug-ins.\nThere is a special case: it is possible to make certain packages visible only to a limited set of other plug-ins (“Package Visibility”). This feature can be used between very closely coupled plug-ins to allow a greater visibility than normally. One such case is for test suites, where the test code is kept in a separate plug-in – to avoid getting it into the production system – but it often needs a more enhanced interface in order to test many features. Note though that fragments are a better solution in this case.\n
• #15: The Extensions page is used to browse and edit plug-in extensions. Extensions are the central mechanism for contributing behavior to the platform. Unless your plug-in is a simple Java API library made available to other plug-ins, new behavior is contributed as an extension.\n
• #16: The Extension points page is used to browse and edit extension points defined by the plug-in. Our plug-in's extension points can be used by the plug-in itself or another plug-in.\nPlease note that the name of the extension point is localized – the text is found in plugin.properties with the key ExtPoint.acceleratorConfigurations.\nThe XML file that describes the complete extension point is found as the file schema/acceleratorConfigurations.exsd. More about this in the module “L0015 - Making Extension Points”.\nTo see more about the different plug-ins that make up the Eclipse IDE, browse the “Plug-ins” view of the PDE perspective.\n
• #17: The Build page shows information about the generated runtime libraries. When packaged, platform plug-ins deliver all of their Java classes in JAR libraries. This page defines how the classes that are in source folders during the design time are packaged into the libraries. One source folder and one library have already been set during the project creation by the wizard. You can define more on this page.\nAlthough a plug-in can be divided into multiple .jar files, this should normally be avoided as it means the plug-in must be distributed as a directory instead of a .jar file.\nThe source build side of the tab is only relevant if you wish to distribute source plug-ins either to the public (not so likely) or to other parts of your company that might build on top of your work.\n
• #18: When an IDE or RCP application or product is started under PDE – sometimes called self-hosted – the new process is given a bundle path that includes all development plug-ins as well as the target system plug-ins. Check the osgi.bundles setting in {your-workspace}/.metadata/.plugins/org.eclipse.pde.core/{launch-name}/config.ini.\n
• #19: \n