Extending Eclipse

www.eclipse.org Extending Eclipse Kai-Uwe Mätzel IBM OTI Labs Zurich kai-uwe_maetzel@ch.ibm.com

Overview • Eclipse is more than a Java IDE • it has an open, extensiblearchitecture • 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 Extensible IDE Platform vs. Extensible IDE Plug-ins IDE Plug-ins 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” • Example: extension point for workbench preference UI • Extension - a contribution • Example: specific HTML editor preferences Extensions Plug-in 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 definitionof plug-in contributions Implementationof plug-in contributions • startup time: O(#used plug-ins), not O(# installed plug-ins)

Plug-in identification Other plug-ins needed Location of plug-in’s code Declare contributionthis plug-in makes Declare new extension point open to contributions from other plug-ins Plug-in Manifest plugin.xml <plugin id = “com.example.tool“ version = “2.1.0” name = “Example Plug-in Tool" class = "com.example.tool.ToolPlugin"> <requires> <import plugin = "org.eclipse.core.resources“ version=“2.0.0”/> <import plugin = "org.eclipse.ui“ version = “2.0.1”/> </requires> <runtime> <library name = “tool.jar"/> </runtime> <extension point = "org.eclipse.ui.preferencepages"> <page id = "com.example.tool.preferences" icon = "icons/knob.gif" title = “Tool Knobs" class = "com.example.tool.ToolPreferenceWizard“/> </extension> <extension-point name = “Frob Providers“ 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 • define an extension point schema (optional) • Define an extension interface • Load the defined extensions on demand from the plug-in registry • lazy creation <extension-point id=“imageFilters" name=“Image Filters"/> public interface IImageFilter { Image filter(Image image);}

plug-in B plug-in A contributes extensionpoint P extension implements interface I class C creates, calls Extender Plus: Extension Interface • Typical arrangement • Plug-in A • 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 • Implement the extension interface <extension point="org.demo.imageFilters"> <imageFilter class=“myplugin.GreyFilter"/></extension> 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

Extending Eclipse