In the Plug-in Development Environment (PDE), every plug-in has its own individual project. A plug-in project is typically created with the New Project wizard, although it is possible to upgrade an existing Java project to a plug-in project by adding the PDE nature and the required files (by navigating to Configure | Convert to plug-in project).
com.packtpub.e4.hello.ui
3.5 or greater
com.packtpub.e4.hello.ui
1.0.0.qualifier
Hello
PacktPub
com.packtpub.e4.hello.ui.Activator
No
Creating a plug-in project is the first step towards creating a plug-in for Eclipse. The New Plug-in Project wizard was used with one of the sample templates to create a project.
Plug-ins are typically named in reverse domain name format, so these examples will be prefixed with com.packtpub.e4
. This helps to distinguish between many plug-ins; the stock Eclipse SDK comes with more than 440 individual plug-ins, for example, the Eclipse-developed ones start with org.eclipse
.
The project contains a number of files which are automatically generated, based on the content filled in the wizard. The key files in an Eclipse plug-in are:
META-INF/MANIFEST.MF
: The OSGi manifest describes the plug-in's dependencies, version, and name. Double-clicking it will open a custom editor, which shows the information entered in the wizards; or it can be opened in a standard text editor.The Manifest follows standard Java conventions; continuations are represented by a new line followed by a single space character, and the file must end with a new line. (For example, the maximum line length is 72 characters, although many ignore this.)
plugin.xml
: The plugin.xml
file declares what extensions this plug-in provides to the Eclipse runtime. Not all plug-ins need a plugin.xml
file; headless (non-UI) plug-ins often don't need to have one. Extension points will be covered in more detail later, but the sample project creates an extension for the commands, handlers, bindings, and menus extension points. (If the older Hello World template was chosen, present on 3.7 and older, only the actionSets
extension will be used.)Text labels for the commands, actions, or menus are represented declaratively in the plugin.xml
file, rather than programmatically; this allows Eclipse to show the menu before needing to load or execute any code.
This is one of the reasons Eclipse starts so quickly; by not needing to load or execute classes, it can scale by showing what's needed at the time, and then load the class on demand when the user invokes the action. Java Swing's Actions provides labels and tool tips programmatically, which can result in a slower initialization of the user interface.
build.properties
: This file is used by PDE at development time and at build time. Generally it can be ignored, but if resources are added that need to be made available to the plug-in (such as images, properties files, HTML content, and so on), an entry must be added here as otherwise it won't be found. Generally, the easiest way to do this is by going to the Build tab of the build.properties
file, which will give a tree-like view of the project's contents.This file is an archaic hangover from the days of Ant builds, and is generally useless when using more up-to-date builds such as Maven Tycho, which will be covered in Chapter 10, Automated Builds with Tycho.