Transcript Document

www.eclipse.org
Extending Eclipse
Kai-Uwe Mätzel
IBM OTI Labs Zurich
[email protected]
Overview
■
Eclipse is more than a Java IDE
–
–


■
it has an open, extensible architecture
built out of layers of plug-ins
everybody can contribute plug-ins
“in many ways Eclipse is the Emacs for the 21st
century” – Martin Fowler
Social implications:
– every programmer can be a tool smith
– creating opportunities for further extension makes it
possible for the tool smith to benefit from the work of
others
 it has to be easy to install and manage plug-ins
Platform vs. Extensible IDE
Platform
Extensible IDE
Plug-ins
Plug-ins
IDE
Run-time
 Eclipse is a platform with a small runtime kernel
Eclipse Plug-in Architecture
■
Plug-in - smallest unit of Eclipse function
– Big example: HTML editor
– Small example: Action to create zip files
■
Extension point - named entity for
collecting “contributions”
Extensions
Plug-in
– Example: extension point for workbench
preference UI
■
Extension - a contribution
– Example: specific HTML editor preferences
Extension
Point
Extension
Interface
Eclipse Plug-in Architecture
■
Each plug-in
–
–
–
–
–
–
■
Contributes to 1 or more extension points
Optionally declares new extension points
Depends on a set of other plug-ins
Contains Java code libraries and other files
May export Java-based APIs for downstream plug-ins
Lives in its own plug-in subdirectory
Details spelled out in the plug-in manifest
– Manifest declares contributions
– Code implements contributions and provides API
– plugin.xml file in root of plug-in subdirectory
Tip of the Iceberg
Declarative definition
of plug-in contributions
Implementation
of plug-in contributions
 startup time: O(#used plug-ins), not O(# installed plug-ins)
Plug-in Manifest
plugin.xml
<plugin
Plug-in identification
id = “com.example.tool“
version = “2.1.0”
name = “Example Plug-in Tool"
class = "com.example.tool.ToolPlugin">
Other plug-ins
<requires>
<import plugin = "org.eclipse.core.resources“ version=“2.0.0”/>
needed
<import plugin = "org.eclipse.ui“ version = “2.0.1”/>
</requires>
<runtime>
Location of plug-in’s code
<library name = “tool.jar"/>
</runtime>
<extension
Declare
point = "org.eclipse.ui.preferencepages">
<page id = "com.example.tool.preferences"
contribution
icon = "icons/knob.gif"
this plug-in makes
title = “Tool Knobs"
class = "com.example.tool.ToolPreferenceWizard“/>
Declare new extension point
</extension>
<extension-point
open to contributions from
name = “Frob Providers“
other plug-ins
id = "com.example.tool.frobProvider"/>
</plugin>
Der Plan
Publishers
Extenders “Plus”
Extenders
Configurers
Users
Extender: Contribute an Icon View
■
■
Goal: a plug-in to view the standard Eclipse images
Steps:
– read extension point specifications
– use Plug-in Development Tools to create a plug-in
project and to declare the extension
– use the Java Development Tools to implement the
extension
Extender: Plug-in Development
■
Extenders use PDE to implement plug-ins
■
PDE = Plug-in development environment
■
Built on top of the Eclipse Platform and JDT
■
Specialized PDE editor for plug-in manifest files
■
Templates for new plug-ins
■
PDE runs and debugs another Eclipse workbench
Extender: Development Workspace
■
Plug-ins correspond to Java projects
■
Source projects “projects you are working on”
– consist of plug-in manifest, source
– source can be changed and compiled
■
Binary projects “projects you are browsing only”
–
–
–
–
■
consist of plug-in manifest, plug-in jar, source jar
source can be inspected
must not be compiled
small foot print
Project’s build class path is derived from the required
plug-ins
Extender: Deploying a Plug-in
■
Development time:
– the plug-in code isn’t packaged as a JAR
– executed in a special development mode by PDE
 faster turn-around
■
Deploy:
– package plug-in code as JARs
 deployed plug-in can be installed into a run-time
Eclipse
■
How to:
– describe deployable contents in build.properties
– generate Ant script with PDE
– run Ant
build.properties
source.imageview.jar = src/
Extender Principles
■
Learn from existing extension point
implementations
■
Relevance rule: only contribute when you can
successfully operate
– you are not the only contributor…
■
Declare the package prefixes your plug-in contains
to speed-up class loading
<runtime>
<library name="runtime.jar">
<packages prefixes="org.eclipse.core"/>
</library>
</runtime>
Extender Plus: Open up your Plug-in
■
Define an extension point in the manifest file
<extension-point id=“imageFilters" name=“Image Filters"/>
– define an extension point schema (optional)
■
Define an extension interface
public interface IImageFilter {
Image filter(Image image);
}
■
Load the defined extensions on demand from the
plug-in registry
 lazy creation
Extender Plus: Extension Interface
■
Typical arrangement
plug-in A
extension
point P
interface I
■
Plug-in A
plug-in B
contributes
implements
extension
class C
creates, calls
– Declares extension point P (org.demo.imageFilter)
– Declares interface I (org.demo.views.IImageFilter) for P
■
Plug-in B
– Implements interface I with its own class C (GreyFilter)
– Contributes class C to extension point P
■
Plug-in A instantiates C and calls its I methods
Consuming an Extension Point
■
Define the extension
<extension point="org.demo.imageFilters">
<imageFilter class=“myplugin.GreyFilter"/>
</extension>
■
Implement the extension interface
public class GreyFilter implements IImageFilter {
public Image filter(Image image) {…}
}
Demo
Extension Points Principles
■
Whenever possible - let others contribute to your
contributions
■
Contributions are additions to Eclipse
– “add, don’t replace”
■
Lazy loading rule: load extensions only when they
are about to be called
■
Contributions do not
– override existing behavior
– remove or replace existing component
– harm existing or future contributions
Extension Points Principles
■
Extension point providers must…
– cope with multiple contributions
• support user arbitration when there are conflicting
contributions
• allow for additive behavior
– protect their code when creating extensions
■
Make your published API explicit
– internal classes should be in internal packages
Publisher: Install/Update
■
Features group plug-ins into installable chunks
– Feature manifest file
■
Plug-ins and features bear version identifiers
– major . minor . service
– Multiple versions may co-exist on disk
■
Features downloadable from web site
– Using Eclipse Platform update manager
– Obtain and install new plug-ins
– Obtain and install updates to existing plug-ins
Publisher: Create a Feature
■
Feature describes
– Contained plug-ins and their versions
– Pre-requisite plug-ins for the feature
<feature
id="org.demo.imageviewfeature“ version="1.0.0">
<requires>
<import plugin="org.eclipse.core.resources"/>
<import plugin="org.eclipse.ui"/>
</requires>
<plugin
id="org.demo.imageview"
download-size="0"
install-size="0"
version="1.0.0"/>
</feature>
Publisher: Create an Update Site
■
An update site
–
–
–
–
is any URL addressable location
contains zips for the feature and plug-ins
version information encoded in the zip name
contents described by a site.xml file
<site>
<feature url="features/org.demo.imageview_1.0.3.jar“>
<category name=“demos" />
</feature>
<category-def name=“demos" label=“Demo Plugins">
<description>Eclipse Demo Plugins</description>
</category-def>
</site>
Publisher Principles
■
Once you have invited others to contribute try hard
to keep your API stable
■
API stability “work arounds”
– deprecate and forward
– start over in a new package
– extension interfaces
Closing the Circle
■
Now that we have published a plug-in with
extension points we have closed the circle:
 Extenders can now extend the extensions!
Plug-in Architecture - Summary
■
All functionality provided by plug-ins
– Includes all aspects of Eclipse Platform itself
■
Contributions via extension points
– Extensions are created lazily
■
Packaged into separately installable features
– Downloadable