Building Eclipse Plugins

Developing Eclipse Plugins
לירן זילכה
מנכ"ל משותף
Liran.zelkha@alunasoft.com

Aluna
Israel’s leading Java/JavaEE and SOA consulting company
Customers:

Eclipse plug-in architecture
Some of this material was taken from a plug-in course developed by the ECESIS project.

Flexible, structured around extension points and plug-ins
This architecture allows for:
Other tools to be used within the platform
Other tools to be further extended
Integration between tools and the platform
No need to wait for new product releases

Tool
(plug-in)
Tool
(plug-in)
Tool
(plug-in)
Plug-in
Developer
Environment
(PDE)
Java
Development
Tooling
(JDT)
Eclipse Platform
Workbench
Help
JFace
SWT
…
Workspace
Team
Platform Runtime
Eclipse SDK

Platform runtime
In the Eclipse, everything is plug-in except the Platform Runtime (the kernel)
All other subsystems build up on the Platform Runtime following the rules of plug-ins
The Basic platform includes:
Resources Management
Workbench
Team
Debug
Help

Extension points
Describe additional functionality that could be integrated with the platform
External tools extend the platform to bring specific functionality
Java Development Tooling (JDT) and Plug-in Development Environment (PDE) are external tools integrated with the platform

Extension points
There are two levels of extending Eclipse:
Extending core platform
Extending existing extensions
Extension points may have a corresponding API interface
Describes what should be provided in the extension

Plug-ins
Define extension points
Each plug-in defines its own set of extension points
Implement specialized functionality
Usually key functionality that does not already exist in the platform
Provide their own set of APIs
Used for further extension of their functionalities
Are external, but fully integrated

Plug-ins
Implement behavior defined through extension point API interface
Can extend named extension points from Eclipse or extension points of other plug-ins
Can declare an extension point and provide an extension to it
Are developed in Java programming language

What's in a plug-in?
A JAR file
An archive with the plug-in code
plugin.xml
Manifest that describes plug-in
about.html
Textual description of the plug-in
plugin.properties
Plugin-in properties

Describing plug-ins
An extension to the platform has to be registered somewhere
Each plug-in has a manifest file that describes:
Location of the plug-in code
Extensions added by the plug-in

Describing plug-ins
The manifest file is plugin.xml.
There are Eclipse tools that make it easy to edit the file without using XML directly.
The manifest describes:
Name, id, and version of the plug-in
List of other plug-ins (and versions) required by the plug-in described
Extension points
Where the plug-in code is located

Example manifest file
<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.0"?>
<plugin
name="Helloworld plug-in"
id="com.examples.helloworld"
version="1.0.0“
provider-name="EXAMPLE"
class="com.example.helloworld.HelloworldPlugin"> >
<requires>
<import plugin="org.eclipse.ui"/>
<import plugin="org.eclipse.core.runtime"/>
<import plugin="org.eclipse.core.runtime.compatibility"/>
</requires>
<runtime>
<library name="helloworld.jar">
<export name="*"/>
</library>
</runtime>
<extension point="org.eclipse.ui.views">
<category name="Hello Category" id="com.example.helloworld"> </category>
<view
name="Hello View" icon="icons/sample.gif" category="com.example.helloworld" class="com.example.helloworld.HelloWorldView" id="com.example.helloworld.HelloWorldView">
</view>
</extension>
</plugin>

Packaging plug-ins
Plug-ins are packaged as Java Archives – JAR files
Archives are named using naming convention:
<id>_<version>.jar
<id> is the identifier
<version> is the full version number from the manifest file
For example: org.eclipse.demo. plugin.simple_1.0.jar

Publishing plug-ins
Used for preparing plug-in for deployment on a specific platform
Manual publishing makes use of Ant scripts
Ant is a open source build tool, commonly used in building processes with Java code
Ant scripts are Java based (platform independent) with XML configuration
Ant is supported in Eclipse

Publishing plug-ins
Automatic publishing is available by using Eclipse wizards
You don't have to use Ant scripts
Wizards allow publishing in a single zip file. A single zip file can contain multiple plug-ins.

Installing plug-ins
Plug-ins are installed under the plugins directory under the Eclipse installation directory
Usually c:eclipseplugins on Windows platforms

Plug-in fragments
Used for extending existing plug-ins
Provide an additional functionality to existing plug-ins
Ideal for providing add-on functionality to plug-ins
Packaged in separate files
Fragment content is treated as it was original plug-in archive
At runtime the platform detects fragments and merges their content with the original plug-in

Plug-in fragments
Described in fragment.xml files
Similar to plug-in manifest files
Plug-in archive can contain plug-ins or fragments

Eclipse API
Meant to be used by plug-in developers
API elements are documented and completely specified
The API elements specify what they are supposed to do and how they are intended to be used.

Eclipse API
The Eclipse platform code is separated into:
API packages
Contain API elements
Non-API packages
Contain internal platform implementation

Using the Eclipse API
The API can be used by doing one of the following:
Instantiating platform API classes
Subclassing platform API classes
Calling public API methods
Most commonly used
Calling protected API methods
Possible from API subclasses

Using the Eclipse API
More ways to use the API:
Overriding API methods
Allowed for some methods
Implementing platform API interfaces
Accessing Fields in API classes and interfaces
Mainly final, read-only fields