1. Eclipse Architecture Dwight Deugo (dwight@espirity.com) Nesa Matic (nesa@espirity.com) www.espirity.com

2. 2 © 2003-2005, Espirity Inc. Additional Contributors None as of September, 2005

3. 3 © 2003-2005, Espirity Inc. Module Overview 1.Eclipse Architecture

4. 4 © 2003-2005, Espirity Inc. Module Road Map 1.Eclipse Architecture  Basic architecture  Platform runtime  Extension points  Plug-ins  Eclipse API  Integration Framework

5. 5 © 2003-2005, Espirity Inc. Eclipse Architecture… Flexible, structured around:  Extension points  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 for the integration

6. 6 © 2003-2005, Espirity Inc. …Eclipse Architecture Eclipse Platform Platform Runtime … Tool (plug-in) Tool (plug-in) Tool (plug-in) Workbench Workspace Help Team JFace SWT Plug-in Developer Environment (PDE) Java Development Tooling (JDT) Eclipse SDK

7. 7 © 2003-2005, Espirity Inc. Platform Runtime In the Eclipse, everything is plug-in except the Platform Runtime  It is a small kernel that represents base of the platform All other subsystems build up on the Platform Runtime following the rules of plug-ins  They are plug-ins themselves Basic platform includes:  Resources Management  Workbench  Team  Debug  Help

8. 8 © 2003-2005, Espirity Inc. 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 There are two levels of extending in Eclipse:  Extending core platform  Extending existing extensions Extension points may have corresponding API interface  Describes what should be provided in the extension

9. 9 © 2003-2005, Espirity Inc. Plug-ins… External tools that provide additional functionality to the platform  Fully integrated with the platform 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

10. 10 © 2003-2005, Espirity Inc. …Plug-ins Plug-ins implement behavior defined through extension point API interface Plug-in can extend:  Named extension points  Extension points of other plug-ins Plug-in can also declare an extension point and can provide an extension to it Plug-ins are developed in Java programming language

11. 11 © 2003-2005, Espirity Inc. What Makes Up a Plug-in? Plug-in consists of:  JAR file  Archive that contains plug-in code  plugin.xml  describes extension points  about.html  Textual description of the plug-in  plugin.properties  Plugin-in properties  META-INF\manifest.mf  describes the plug-in

12. 12 © 2003-2005, Espirity Inc. 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 Manifest file is META-INF\MANIFEST.MF  Can be edited with Eclipse tools  Usually describes:  Name, id, and version of the plug-in  List of other plug-ins required by the plug-in described  Where the plug-in code is located Plugin file is plugin.xml  describes extension points

13. 13 © 2003-2005, Espirity Inc. Example Manifest File Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Demo Plug-in Bundle-SymbolicName: Demo; singleton:=true Bundle-Version: 1.0.0 Bundle-Activator: demo.DemoPlugin Bundle-Localization: plugin Require-Bundle: org.eclipse.ui, org.eclipse.core.runtime Eclipse-AutoStart: true

14. 14 © 2003-2005, Espirity Inc. Example plugin.xml File <extension point="org.eclipse.ui.actionSets"> <actionSet label="Sample Action Set" visible="true" id="Demo.actionSet"> <menu label="Sample &Menu" id="sampleMenu"> <separator name="sampleGroup"> <action label="&Sample Action" icon="icons/sample.gif" class="demo.actions.SampleAction" tooltip="Hello, Eclipse world" menubarPath="sampleMenu/sampleGroup" toolbarPath="sampleGroup" id="demo.actions.SampleAction">

15. 15 © 2003-2005, Espirity Inc. Packaging Plug-ins Plug-ins are packaged as Java Archives – JAR files Archives are named using naming convention: _.jar  is identifier  is full version from the manifest file  For example: org.eclipse.demo.plugin.simple_1.0

16. 16 © 2003-2005, Espirity Inc. 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 Automatic publishing is available by using Eclipse wizards  It shields from using Ant scripts  Wizards allow publishing in a single zip file  The zip file contains multiple plug-ins

17. 17 © 2003-2005, Espirity Inc. Installing Plug-ins Plug-ins are installed under \plugins\ directory off the Eclipse installation directory, e.g: c:\eclipse\plugins

18. 18 © 2003-2005, Espirity Inc. 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  During the runtime platform detects fragments and merges their content with original plug-in Described in the fragment.xml files  Similar to plug-in manifest files  Plug-in archive can contain plug-ins or fragments

19. 19 © 2003-2005, Espirity Inc. Eclipse API Meant to be used by plug-in developers API elements are documented and have specification API elements contain specification about:  What they are supposed to do  How they are intended to be used The Eclipse platform code is separated into:  API packages  Contain API elements  Non-API packages  Contain internal platform implementation

20. 20 © 2003-2005, Espirity Inc. Using 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  Overriding API methods  Allowed for some methods  Implementing platform API interfaces  Accessing Fields in API classes and interfaces  Mainly final, read-only fields

21. 21 © 2003-2005, Espirity Inc. An Eclipse feature is a collection of plug-ins  Represents smallest unit of separately downloadable and installable functionality  New notion in Eclipse since version 2.0  Replaces notion of “component” in Eclipse 1.0 Features plug-in3plug-in4 plug-in1plug-in2 feature

22. 22 © 2003-2005, Espirity Inc. Update Manager Can be used with features and plug-ins for:  Discovering  Downloading  Installing Supported by modular nature of Eclipse  Makes it easy to install additional features and plug-ins, and to update existing ones Installing or updating features and plug-ins requires adding files to Eclipse  Deleting files is never required as different version can co-exist in Eclipse

23. 23 © 2003-2005, Espirity Inc. Tools Integration Framework Eclipse is the framework for integrating different tools  Vendors provide the tools  Eclipse provides the integration Eclipse provides multiple levels for integration  Tool vendor must follow the rules for allow integration at the certain level From users point of view it is all one tool  Eclipse provides seamless integration, users don’t know when they’re using different tools

24. 24 © 2003-2005, Espirity Inc. Invocation Integration Launches tools in external process Used for integration of existing tools that are platform dependent  Tools can use Eclipse facilities such as resource management and project model  Tools cannot run within the Workbench and use other tools within Eclipse  Tools run in separate windows Eclipse could be used by developers as a central point for navigating and manipulating resources

25. 25 © 2003-2005, Espirity Inc. Data Integration Allows tools to share the data It is supported through:  Access method, specifies how application can access data from other applications  Interchange protocol, specifies the form of data  Data transformation, used for transforming data in more appropriate format Tool data should be stored in a standard format to support data integration  XML for example  It is up to tool vendor to provide the format

26. 26 © 2003-2005, Espirity Inc. API Integration Allows data access through tool specific API  Isolates data from direct access such as in data integration  Tool vendor specifies Java client API for accessing data  Non Java tools must also have Java API, which is possible to do through Java Native Interface (JNI) Promotes behavioral reuse by reusing client API  Data integration promotes reuse of data state

27. 27 © 2003-2005, Espirity Inc. UI Integration Allows tools to integrate at the UI level  It looks like the tools are all part of the same application  It is supported by a tool specifying with which tools to integrate at the run time The UI for the tool must be implemented using Eclipse UI framework  Integration with Workbench is done through extension points

28. 28 © 2003-2005, Espirity Inc. Other Integrations Event listening, by registering interest in other tools events Selection management is an example:  Tool provides selection provider  Tool listens for selection events  Selection listeners are notified by the Workbench of any change in the selection  Tool can modify its UI based on the notification received

29. 29 © 2003-2005, Espirity Inc. Summary You have learned:  Basic architecture  Eclipse extension points  Eclipse plug-ins  Eclipse API  Integration Framework

30. 30 © 2003-2005, Espirity Inc. Labs! Lab: Eclipse Architecture (Exploring the Plug-ins Directory)