This document summarizes the Eclipse plugin architecture. It describes how plugins extend the Eclipse platform by implementing extension points and APIs. Plugins are packaged as JAR files with a manifest (plugin.xml) describing the plugin. Plugins are installed under the Eclipse plugins directory and can extend both the core platform and other plugins. The Eclipse API is meant to be used by plugin developers to integrate functionality.

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

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

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

4. Eclipse plug-in architecture 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

5. Eclipse plug-in architecture 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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