Developing Eclipse Plugins לירן זילכה מנכ"ל משותף Liran.email@example.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.
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
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
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