Transcript Eclipse Platform

TOOLS FOR DESIGN AND DEVELOPMENT
ENVIRONMENTS.
Case study - ECLIPSE
Lecture notes 1
Eclipse Platform
MAIN CHARACTERISTICS
•
•
•
•
“IDE for anything, and for nothing in particular”
a lot of, most generic, built-in functionality
built on a mechanism for discovering, integrating, and running modules called
plug-ins
launched as an integrated development environment (IDE) composed of the set
of available plug-ins
MAIN ROLE – provides:
• mechanisms to use, and rules to follow by tool providers, that lead to
seamlessly-integrated tools
• useful building blocks and frameworks that facilitate developing new tools
Eclipse Platform
•
Functional architecture - building blocks that add new features to the core
runtime platform.
Several hundred Eclipse subprojects and independent open source or commercial products build on this
platform.
•
•
•
•
•
•
Generic IDE support, further specialized for Java, C/C++, Web Tools, and other
development activities.
Generic IDE - team-oriented workbench supporting multiple perspectives,
views, search facilities, debugging, and more.
Java Development Tools (JDT) adds specific support for configuring Java
projects and a rich environment for editing and debugging.
Other languages, such as C/C++, are supported with optional plug-in features
available from the Eclipse Web site and other independent projects.
Web Tools Platform (WTP) - extensible, standards-based platform for J2EE and
Web-centric applications development.
Eclipse Platform supports and accelerates the iterative agile development
cycle.
Specialized features are included for continuous testing, refactoring, continuous integration, collective
ownership, and coding standards.
Eclipse Platform architecture
Major components and APIs
Eclipse Platform plug-ins
Def. Plug-in = structured bundles of code and/or data that contribute function to the
system.
The smallest unit of Eclipse Platform function that can be developed and delivered
separately.
•
•
small tool - written as a single plug-in
complex tool - functionality split across several plug-ins
Platform's functionality located in:
- small kernel - Platform Runtime
- plug-ins
Plug-in
- coded in Java
- consists of
- Java code in a JAR library
(Java classes with public API)
-
located together either:
- in a directory in the file system
- at a base URL on a server
read-only files
other resources (images, web templates, message catalogs, native code libraries, etc.)
Obs.
1. Some plug-ins do not contain code at all. One such example is a plug-in that contributes online help in the form of HTML pages.
2. A mechanism exists that permits a plug-in to be synthesized from several separate fragments, each in their own directory or URL. This is
the mechanism used to deliver separate language packs for an internationalized plug-in.
Eclipse Platform plug-ins
Def. Extension point
= well-defined place where plug-ins can add functionality.
Def. Platform extension point = function point for the platform that plug-ins can plug
into.
Def. Plug-in extension point = extension point defined by a plug-in.
Def. Extension point schema = an XML schema that defines a grammar that formally
expresses elements, attributes, and types.
Can be used by tools to validate extensions or offer assistance during the creation of extensions.
Extension point - may have a corresponding API interface.
Extension to an extension point = implementation of this interface.
Def. Manifest file
= the file attached to a plug-in to declare its interconnections to
other plug-ins (dependences and services).
Interconnection model: a plug-in declares:
- any number of named extension points that can be extended by other plug-ins
An extension point may have a corresponding API interface. Other plug-ins contribute implementations of this
interface via extensions to this extension point.
Any plug-in is free to define new extension points and to provide new API for other plug-ins to use.
-
any number of extensions to one or more extension points in other plug-ins.
For example, the workbench plug-in declares an extension point for user preferences. Any plug-in can contribute its
own user preferences by defining extensions to this extension point.
Plug-in mechanism
On start-up, the Eclipse Platform Runtime:
- discovers the set of available plug-ins
- reads their manifest files
- matches extension declarations by name with their corresponding extension point
declarations
-
detects and log problems (such as extensions to missing extension points)
builds an in-memory plug-in registry.
Plug-in registry is available via the Eclipse Platform API.
Plug-ins cannot be added after start-up.
Plug-in operates on files in the workspace and surfaces its tool-specific UI in the
workbench(desktop development environment).
Plug-in manifest file
XML file (plugin.xml file) that contains:
- Declarations of additional specialized XML element types for use in the
extensions.
Manifest information (MANIFEST.MF file):
- Communicated by the plug-in supplying the extension to to the plug-in
declaring the corresponding extension point.
- Available from the plug-in registry without activating the contributing plugin or loading of any of its code.
Advantages:
- supporting a large base of installed plug-ins only some of which are needed in any
given user session.
- negligible memory footprint and impact on start-up time for plug-ins not yet loaded.
- easy to write tools that support plug-in creation.
The Plug-In Development Environment (PDE), which is included in the Eclipse SDK, is such a tool.
Plug-in activation
The Eclipse Platform Runtime declares a special extension point for applications.
Launching an instance of the Platform:
- the name of an application is specified via the command line
- initially is activated only the plug-in that declares that application.
Platform provides each plug-in with a rich source of pertinent information about the
context in which it is operating without actually creating the whole context
 avoids lengthy start-up sequence (as is a common source of bugs stemming from unpredictable
plug-in activation order).
Context cannot change while the Platform is running
 there is no need for complex life cycle events to inform plug-ins when the context
changes.
Plug-in activation
The Eclipse Platform is run by a single invocation of a standard Java virtual machine.
Each plug-in is assigned its own Java class loader that is solely responsible for loading
its classes (and Java resource bundles).
The visibility rules for public classes and interfaces in plug-in’s libraries are enforced at
runtime by the plug-in class loaders as declared in the manifest file.
Plug-in activation
Activated when its code actually needs to be run.
Activation = uses a small number of API methods for explicitly activating plug-ins.
Activated plug-in:
- uses the plug-in registry to discover and access the extensions contributed to its
extension points; this can be done using only the information from the registry,
without having to activate any of the contributing plug-ins.
- remains active until the Platform shuts down.
- can carry over important state between runs using a mechanism that furnishes a
subdirectory in which to store plug-in-specific data.
Plug-in supporting mechanisms
Update manager:
- downloads and installs new features or upgraded versions of existing features (a
feature being a group of related plug-ins that get installed and updated together).
- constructs a new configuration of available plug-ins to be used the next time the
Eclipse Platform is launched.
If the result of upgrading or installing proves unsatisfactory, the user can roll back to an earlier
configuration.
Extending objects dynamically:
- a class that implements an “adaptable” interface declares its instances open to
third party behavior extensions.
- an adaptable instance can be queried for the adapter object that implements an
interface or class.
For example, workspace resources are adaptable objects; the workbench adds adapters that provide a suitable icon
and text label for a resource.
Plug-in supporting mechanisms
Extending objects dynamically (continued)
-
Any party can add behavior to existing types (both classes and interfaces) of
adaptable objects by registering a suitable adapter factory with the Eclipse
Platform.
-
Multiple parties can independently extend the same adaptable objects, each for a
different purpose.
-
When an adapter for a given interface is requested, the Eclipse Platform identifies
and invokes the appropriate factory to create it.
-
The mechanism uses only the Java type of the adaptable object (it does not
increase the adaptable object's memory footprint).
-
Any plug-in can exploit this mechanism to add behavior to existing adaptable
objects, and to define new types of adaptable objects for other plug-ins to use and
possibly extend.
Fundamental plug-ins
-
Java development tools (JDT) - implement a full featured Java development
environment.
-
Plug-in Developer Environment (PDE) - adds specialized tools that streamline the
development of plug-ins and extensions.
Workspaces
The resource types and relations on Eclipse Platform:
Each instance of this model is a
hierarchical structure with a
singleton workspace as root.
•
•
•
Tools plugged in to the Eclipse Platform operate on regular files in the user's
workspace.
The workspace consists of one or more top-level projects,
Each project maps to a corresponding user-specified folder in the file system.
The different projects in a workspace may map to different file system directories or drives, although, by default,
all projects map to sibling subdirectories of a single workspace directory.
The workspace is a directory hierarchy containing both
user files (such as projects, source code, etc.)
plug-in state information (such as preferences).
Workspace resources
Workspace resources = collective term for projects, files, and folders.
Are platform-independent.
Tools integrated with the Eclipse Platform are provided with API for dealing with
Workspace resources
Workspace resources are represented by adaptable objects so that other parties
can extend their behavior.
Resources - stored and displayed in hierarchies.
Terminology: Root , Parent resource, Child resource
Resource hierarchies are displayed in the Project Explorer view, which is one of the default views in the
Resource perspective.
Workspaces resources : Projects
Def. Project = entity in the workspace that carry metadata about project
characteristics and contribute automatic behavior when its resources are
modified.
Is a container that groups resource into buildable, reusable units.
Features:
- an hierarchy of files and folders
- location – local file system
- build specification control – defines the way its resources are built
- properties: session and persistent
- state: opened or closed (passive; minimal in-memory footprint)
- can refer to other projects
- can have one or more project natures
Workspaces resources : Projects
Project nature = a tagged particular personality, or nature, of a project.
For example
- Web site nature tags a project that contains the static content for a web
site
- Java nature tags a project that contains the source code for a Java
program.
The project nature mechanism:
- is open,
- plug-ins may declare new project natures and provide code for
configuring projects with that nature,
- a single project may have as many natures as required,
- affords a way for tools to share a project without having to know about
each other.
Workspace resources: Files and Folders
Files:
- created and manipulated by the user
- directly accessible to the standard programs and tools of the underlying
operating system.
Mechanisms for managing resources
Low-level workspace history mechanism - keeps track of the previous
content of any files that have been changed or deleted by integrated
tools.
The user controls how the history is managed via space- and age-based preference settings.
Allows restore the previous version of a file (including undelete).
Only files have local history; projects and folders do not.
Marker mechanism for annotating resources.
Ex of annotations:
compiler error messages
to-do list items
bookmarks
search hits
debugger breakpoints.
The marker mechanism is open  plug-ins can:
- declare new marker subtypes
- control whether they should be saved between runs.
Mechanisms for managing resources
General mechanism used to track changes to workspace resources.
A tool:
- registers a resource change listener
- receives after-the-fact notifications of all resource creations, deletions, and
changes to the content of files.
Eclipse Platform defers the event notification until the end of a batch of resource
manipulation operations.
Event reports take the form of a tree of resource deltas that describe the effect of the
entire batch of operations in terms of net resource creations, deletions, and
changes. Resource deltas also provide information about changes to markers.
Resource tree deltas are particularly useful and efficient for tools that display resource trees, since
each delta points out where the tool may need to add, remove, or refresh on-screen widgets.
In addition, since a number of semi-independent tools may be operating on the
resources of a project at the same time, this mechanism allows one tool to detect
the activity of another in the vicinity of specific files, or file types, in which it has an
interest.
Building
Def. Build = process that derives new resources from existing ones, updates existing
resources, or both.
Different builders - invoked for different types of projects.
For example, when a build is triggered for a Java project, a Java builder converts each Java source file (.java files)
into one or more executable class files (.class files). Builders usually enforce the constraints of some domain.
For example, a Web link builder could update links to files whose name/location changes.
Kinds of builds:
- incremental build - leverages a previously built state and applies the transforms of
the configured builders to the resources that have changed since the previous
state was computed (that is, since the last build).
- clean build - discards any problems and previously built state. The next build after
a clean will transform all resources according to the domain rules of the configured
builders.
Obs. Incremental and clean builds can be done over a specific set of projects or the workspace as
a whole. Specific files and folders cannot be built.
Building
Ways builds can be performed:
-
Automatic – builds are performed as resources are saved.
Automatic builds are always incremental and always operate over the entire workspace. You can
configure your preferences ( Window > Preferences > General > Workspace) to perform
builds automatically on resource modification.
-
Manual – builds are initiated when you explicitly select a menu item or press the
equivalent shortcut key.
Manual builds can be either clean or incremental.
Mechanisms for managing resources
Incremental project builder framework = mechanism used by tools like compilers
and link checkers in order to apply a coordinated analysis and transformation of
(thousands of) separate files
 provide scalable solutions.
Input - resource tree delta capturing the net resource differences since the last build.
Several different incremental project builders may be registered on the same project.
Ways to trigger project and workspace-wide builds are provided.
An optional workspace auto-build feature automatically triggers the necessary builds
after each resource modification operation (or batch of operations).
Mechanisms for managing resources
Workspace save-restore process
-
is open to participation from plug-ins wishing to remain coordinated with the
workspace across sessions
-
a two-phase save process ensures that the important state of the various plug-ins
are written to disk as an atomic operation
-
in a subsequent session, when an individual plug-in gets reactivated and rejoins
the save-restore process, it is passed a workspace-wide resource delta describing
the net resource differences since the last save in which it participated
-
allows a plug-in to carry forward its saved state while making the necessary
adjustments to accommodate resource changes made while it was deactivated.