Extending Eclipse

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

2. 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

3. Platform vs. Extensible IDE Platform Extensible IDE

4. 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

5. 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

6. Tip of the Iceberg

7. Plug-in Manifest [Contains animated elements] [Contains animated elements]

8. Der Plan

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. Extender Plus: Extension Interface 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

16. Consuming an Extension Point Define the extension Implement the extension interface

17. 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

18. 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

19. 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

20. Publisher: Create a Feature Feature describes Contained plug-ins and their versions Pre-requisite plug-ins for the feature

21. 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

22. 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

23. 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!

24. 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 [Contains animated elements] [Contains animated elements]