Eclipse ArchitectureEclipse Architecture

Dwight Deugo (dwight@espirity.com)Dwight Deugo (dwight@espirity.com)Nesa Matic (nesa@espirity.com)Nesa Matic (nesa@espirity.com)

www.espirity.com

2 © 2003-2005, Espirity Inc.

Additional Contributors

None as of September, 2005

3 © 2003-2005, Espirity Inc.

Module Overview

1. Eclipse Architecture

4 © 2003-2005, Espirity Inc.

Module Road Map

1. Eclipse Architecture Basic architecture Platform runtime Extension points Plug-ins Eclipse API Integration Framework

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 © 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 © 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 © 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 © 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 © 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 © 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 © 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 © 2003-2005, Espirity Inc.

Example Manifest File

Manifest-Version: 1.0Bundle-ManifestVersion: 2Bundle-Name: Demo Plug-inBundle-SymbolicName: Demo; singleton:=true

Bundle-Version: 1.0.0Bundle-Activator: demo.DemoPluginBundle-Localization: pluginRequire-Bundle: org.eclipse.ui, org.eclipse.core.runtimeEclipse-AutoStart: true

14 © 2003-2005, Espirity Inc.

Example plugin.xml File<?xml version="1.0" encoding="UTF-8"?><?eclipse version="3.0"?><plugin> <extension point="org.eclipse.ui.actionSets"> <actionSet label="Sample Action Set" visible="true" id="Demo.actionSet"> <menu label="Sample &amp;Menu" id="sampleMenu"> <separator name="sampleGroup"> </separator> </menu> <action label="&amp;Sample Action" icon="icons/sample.gif" class="demo.actions.SampleAction" tooltip="Hello, Eclipse world" menubarPath="sampleMenu/sampleGroup" toolbarPath="sampleGroup" id="demo.actions.SampleAction"> </action> </actionSet> </extension></plugin>

15 © 2003-2005, Espirity Inc.

Packaging Plug-ins

Plug-ins are packaged as Java Archives – JAR files

Archives are named using naming convention:<id>_<version>.jar

<id> is identifier <version> is full version from the manifest file

For example: org.eclipse.demo.plugin.simple_1.0

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 © 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 © 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 © 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 © 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 © 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-in3 plug-in4

plug-in1 plug-in2

feature

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 © 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 © 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 © 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 © 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 © 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 © 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 © 2003-2005, Espirity Inc.

Summary

You have learned: Basic architecture Eclipse extension points Eclipse plug-ins Eclipse API Integration Framework

30 © 2003-2005, Espirity Inc.

Labs!

Lab: Eclipse Architecture (Exploring the Plug-ins Directory)