The plug-in class
So far, we've been looking at the different extensions that are provided by the readme tool. Let's look at the general
definition of the readme tool plug-in.
The readme tool plug-in is defined in the MANIFEST.MF file.
Bundle-SymbolicName: org.eclipse.ui.examples.readmetool; singleton:=true
Eclipse-AutoStart-comment: Use Eclipse-AutoStart instead of Eclipse-LazyStart because the readme example should run against 3.1 as well as 3.2.
The plug-in definition includes the Bundle-Name, Bundle-SymbolicName (plug-in id),
Bundle-Version, and Bundle-Vendor of the plug-in. We
saw most of these parameters before in our hello world plug-in. The readme tool also defines a specialized plug-in class,
The name of the jar file is also provided. File names specified in Bundle-ClassPath are relative to the
plug-in's directory, so the readme tool's jar file should be located directly in the plug-in's directory.
The Require-Bundle element informs the platform of the readme tool's dependencies.
The workbench UI plug-ins are listed as required plug-ins, along with the various core, jface, and text plug-ins.
The ReadmePlugin class represents the readme
tool plug-in and manages the life cycle of the plug-in. As we saw in the
Hello World example, you don't have to specify a plug-in class. The
platform will provide one for you. In this case, our plug-in needs to
initialize UI related data when it starts up. The platform class
provides a structure for managing UI resources and is extended by
uses the generic startup and shutdown methods to manage images, dialog settings, and a preference store during the lifetime of the plug-in.
We'll look at the specifics of the ReadmePlugin class when we work with dialogs and preferences.