UNIVERSITY OF CALIFORNIA,
IRVINE
The Integration of Palantı́r into the Eclipse Open Source Platform
THESIS
submitted in partial satisfaction of the requirements
for the degree of
MASTER OF SCIENCE
in Information and Computer Science
by
Ryan Yukio Yasui
Thesis Committee:
Professor André van der Hoek, Chair
Professor David F. Redmiles
Professor Susan E. Sim
2004
c 2004 Ryan Yukio Yasui
The thesis of Ryan Yukio Yasui is approved:
Committee Chair
University of California, Irvine
2004
ii
To my family
iii
TABLE OF CONTENTS
LIST OF FIGURES
vi
LIST OF TABLES
vii
ACKNOWLEDGMENTS
viii
ABSTRACT OF THE THESIS
ix
1 Introduction
1
2 Literature Review
2.1 Definitions of Tool Integrations
2.1.1 Presentation . . . . . . .
2.1.2 Data . . . . . . . . . . .
2.1.3 Control . . . . . . . . .
2.1.4 Process . . . . . . . . .
2.2 Event-Based Integration . . . .
2.3 Problems in Integration . . . .
2.3.1 Heterogeneity . . . . . .
2.3.2 Architectural Mismatch
2.4 Analysis of Related Literature .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
4
5
6
7
8
9
9
9
11
3 Problem Statement
3.1 Palantı́r Architecture . . .
3.1.1 Event Wrapper . .
3.1.2 Event Service . . .
3.1.3 Internal State . . .
3.1.4 Extractor . . . . .
3.1.5 Visualization . . .
3.2 Eclipse Architecture . . .
3.2.1 Platform Runtime .
3.2.2 Workspace . . . . .
3.2.3 SWT . . . . . . . .
3.2.4 JFace . . . . . . .
3.2.5 Workbench . . . .
3.3 Eclipse Plug-in Creation .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
13
13
14
15
15
15
16
17
17
18
18
18
18
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
iv
3.4
Analysis of the Architectures . . . . . . . . . . . . . . . . . . . . . . .
19
4 Approach
20
5 Implementation with a CVS Repository
5.1 Event Wrapper Modifications . . . . . . . . . . . . . . . . . . . . . .
5.2 Conversion of Palantı́r Visualizations to Eclipse Views . . . . . . . . .
22
22
26
6 Implementation with a Subversion Repository
29
7 Validation Plan
7.1 Example Development Scenario
7.2 Verification of the Integration .
7.2.1 Presentation . . . . . . .
7.2.2 Data . . . . . . . . . . .
7.2.3 Control . . . . . . . . .
7.2.4 Process . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
31
31
32
32
33
34
34
8 Analysis of the Integration
35
9 Conclusion
37
Bibliography
38
v
LIST OF FIGURES
3.1
3.2
Palantı́r Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
Eclipse Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
16
5.1
5.2
Architecture of the Palantı́r/Eclipse Integration . . . . . . . . . . . .
Screenshot of the Impact and Severity Triangles . . . . . . . . . . . .
25
27
vi
LIST OF TABLES
3.1
Palantı́r Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
14
ACKNOWLEDGEMENTS
Acknowledgements go here
viii
ABSTRACT OF THE THESIS
The Integration of Palantı́r into the Eclipse Open Source Platform
By
Ryan Yukio Yasui
Master of Science in Information and Computer Science
University of California, Irvine, 2004
Professor André van der Hoek, Chair
The current implementation of Palantı́r, a Configuration Management workspace
awareness tool, is very mature, with integrations with RCS, CVS and Subversion.
However, these integrations are limited to the Configuration Management system,
restricting the available information to the activities in the repository, and forcing
the developer to use separate tools for all other development tasks. The Eclipse open
source platform is quickly becoming the development environment of choice due to
its tight integration of various development tools including text editors, debuggers,
and source control systems in a single IDE. The Eclipse platform also has facilities for
contributing customized functionality to the platform. This makes it an attractive
choice in which to integrate Palantı́r.
The objective of this thesis is to examine this integration. It determines if such
an integration is possible and describes the architectural characteristics of Palantı́r
and Eclipse that make the integration simple or difficult.
This thesis will examine the general issues surrounding the integration of the two
architectures, describe the particular integration and its use in an example development scenario, and validate the soundness of the integration using a set of well-defined
principles. The experience with the example scenario verified that all functionality
was preserved in the integration. According to the principles used, the integration
also proved to be sound.
ix
Chapter 1
Introduction
Palantı́r, a Configuration Management (CM) workspace tool, is designed to improve
coordination between software developers working in parallel and reduce the number
of conflicts by providing an awareness of the activities in the workspaces of other
developers [SNvdH03]. However, the existing implementation is only integrated with
three Configuration Management systems, RCS, CVS and Subversion, thus restricting
the available information to the activities in the CM repository. In addition, it requires
that the developer uses separate tools for all other development activities. Although
this is fairly common, an environment that combines tools for the majority of software
development tasks is desirable. The Eclipse open source platform can help to provide
this environment. Eclipse is quickly becoming the development IDE of choice. It
has a tight integration of many development tools, including editors, debuggers, and
source control facilities, and allows for the addition of customized functionality to
the platform in the form of a plug-in [Ecl04]. Therefore, Eclipse is a very attractive
candidate for the integration of Palantı́r.
The focus of this thesis is to examine this integration. The Literature Review
will address the basic issues surrounding the integration of architectures, including
some properties of successful integrations, potential road blocks that exist, and an
1
example of a type of integration. The Problem Statement will discuss the specifics of
the two architectures, describing the points at which the integration will occur, and
properties of the architectures that will simplify the integration. The Approach will
briefly describe the steps that were taken to achieve the integration. The Validation
Plan will include the two types of validation that were performed.
2
Chapter 2
Literature Review
A considerable amount of research has been devoted to the integration of software
environments and tools. From integrated project-support environments (IPSE) to integrated computer-aided software engineering tools (ICASE) to integrated softwareengineering environments (ISEE), there has been a push to develop more effective
tools and integration techniques. One motivation for this is that refining integration techniques can facilitate an increase in the reuse of components, which has been
cited as having the potential for enormous cost savings [Bro95]. In order to take
advantage of the benefits that integrated tools can provide, the meaning of architectural integration and the underlying issues surrounding the integration should be
understood.
2.1
Definitions of Tool Integrations
Thomas and Nejmeh believe that integration is not a property of a tool but of its
relationships with other elements in the environment [TN92]. They extend a subset
of Wasserman’s definitions of the five types of integration: platform, presentation,
data, control, and process integration [Was90]. These types define properties that
characterize the various relationships between tools in an integration. By defining
3
these properties, a determination can be made if the integration meets the expectations of the user, who desires a well integrated tool, and the designer, who desires an
easily integrated tool.
2.1.1
Presentation
The goal of presentation integration is to improve the efficiency and effectiveness of
the user interaction with the tools. In order to do this, Thomas and Nejmeh propose
a number of steps to reduce the cognitive load of the user by letting them reuse their
experience when using the different tools [TN92].
• Reduce the number of interaction and presentation paradigms. Examples of
these paradigms are file system navigation, and hypertext navigation.
• Provide interaction and presentation paradigms that match the user’s mental
model.
• Meet the user’s response time expectations.
• Ensure that accurate and useful information is maintained.
Appearance and Behavior
Appearance and behavior is concerned with the similarities between the tools’ screen
appearance and interaction behavior. This property captures the lexical and syntactic
similarities and differences between the tools’ user interface. Tools are well-integrated
with respect to this property if the user can apply the same experience and expectations to the interface of each tool.
Interaction
The interaction paradigm is concerned with the extent that the tools use the same
metaphors and mental models. Tools are well-integrated if the metaphors and mental
4
models are similar. For example, if a tool uses the desktop metaphor, the tool that
it is integrated with should also use this metaphor.
2.1.2
Data
The goal of the Data property is to ensure that all information is managed consistently,
regardless of the operations that each tool performs on it. There are five properties
of Data integration.
Interoperability
Since the integrated tools will be operating on the same data, it is important that the
amount of work required to make data usable by each tool is minimal. Well-integrated
tools have a common view of the data. The greater the differences in the view of the
data by each tool, the more transformations need to occur for a tool to use the data
of another. These differences can range from different character representations to
different information models.
Nonredundancy
This property is concerned with the amount of data that is stored by each tool and
duplicated by the other tool. The tools are well-integrated if there is little redundant
data. Maintaining consistency of the data across tools is the central problem of
duplicate data. If redundant data is necessary, a strategy must be chosen to update
the data in both tools.
Data Consistency
Cooperation to maintain specific semantic constraints on the data is another measure
to determine how well tools are integrated. The tools must indicate their actions and
the effects of these actions on the constrained data to be considered well-integrated.
5
Data Exchange
Data exchange is similar to Interoperability except that data exchange also refers to
non-persistent data. This can include values that are initially communicated to a tool
before execution, or values communicated during execution. Since tools may exchange
data, they must ensure that the provided data is usable by other tools. An agreement
must exist on the format and semantics of the data. Tools are well-integrated with
respect to this property if little work on format and semantics is needed for the data
exchange.
Synchronization
Synchronization is concerned with the communication of changes to nonpersistent
data made by a tool. A portion of the nonpersistent data needed for execution might
be duplicated across different tools. Changes to the data must be communicated to
other tools that also require this data. Well-integrated tools communicate all such
changes.
2.1.3
Control
Integrated tools must share functionality. Ideally, the functionality of all tools should
be available to all other tools and the provider of the functionality need not be aware of
the users of the functionality. To facilitate sharing, each provider must communicate
the operations to be performed and the requisite data for the operations. There are
two distinct properties of control: provision and use.
Provision
The provision property is concerned with the extent that a tool’s services are used by
other tools in the environment. A tool is well-integrated with respect to this property
if it offers services that other tools use and need.
6
Use
The use property is the extent that a tool uses the services provided by other tools.
A well-integrated tool uses the services of other tools appropriately. The tools must
consider the replacement of its services by the services of other tools to achieve high
use integration. This requires the use of highly-modular tools.
2.1.4
Process
Inherently, a tool has a set of assumptions about the processes in which it may be
used. If the tools have a consistent set of assumptions regarding these processes, they
are well-integrated. The degree of consistency is directly related to the potential for
integration. There are three dimensions of process integration: process step, process
event, and process constraint.
Process Step
The process step dimension measures the degree of cooperation between tools to
produce a result. A process step is a unit of work that yields this result. The step
may be decomposed into sub-steps that are independently executed by the various
tools. Each sub-step may have pre-conditions that must be acheived before it can
execute. If the goals of each process sub-step are achieved, allowing other tools to
attain their goals, the tools are well-integrated.
Process Event
The events that support a process are the concern of the process event dimension. A
process event is a condition that arises during a process step that may result in the
execution of an associated action. How well the tools agree on these events determines
how well they integrate with respect to this dimension. The two aspects of this
7
agreement are that a tool’s preconditions should contain the events generated by other
tools, and that the generated events should help satisfy other tools’ preconditions.
Process Constraint
A process constraint restricts some aspect of the process. In this dimension, how well
the tools integrate depends on how well they cooperate to enforce a constraint. Tools
are well integrated if they make similar assumptions about the range of constraints
that they recognize.
2.2
Event-Based Integration
The definitions listed above describe the types of integrations and their properties.
The approaches to integration can be categorized as loose integration, where components have little or no knowledge of the others, or tight integration, where each
component requires much knowledge about other components. The most prevalent
approach to loose integration is the event-based approach [BCTW96]. Here, the
components react to events that are announced by other components. These events
can be triggered by updates to data that other components are concerned with.
There are two general methods of communication in event-based integration approaches: Point-to-Point and Multicast. In point-to-point communication, data from
one component is sent directly to another component, either through procedure calls
or by sending the data to another component’s unique ID. In multicast communication, data is sent from one component to a set of other components through implicit
invocation or a software bus. Implicit invocation occurs when components express
interests in receiving certain types of data from other components. This is commonly
done with the registration of event listeners. Communication through a software bus
requires that the components’ input and output are bound to an abstract bus. Data
8
sent through the bus channel is received by all components that have an input to that
channel.
2.3
Problems in Integration
The definitions of integration and the discussion of the event-based approach serve as
a clear guide for integrating architectures. However, there have been many problems
encountered when trying to perform an architectural integration. These problems
stem from issues with heterogeneity and mismatched assumptions among the components.
2.3.1
Heterogeneity
In many cases, integration problems exist because the components do not fit well
together. This is caused by heterogeneity between components. Components that are
implemented in different languages, run on different hardware and software platforms,
and have different control and data models cannot simply be connected together and
expected to work properly. Transformations are necessary so that the components
can communicate and interact successfully. The types of transformations needed are
dependent on the type of differences that exist.
2.3.2
Architectural Mismatch
For the most part, these interoperability issues can be overcome. The more difficult
problem is architectural mismatch [GAO95]. This stems from the conflicting and
often implicit assumptions that a component makes about the environment that is
being used. Consequences of architectural mismatch are an excessive amount of code,
poor performance of the integrated system, the need to modify external packages
and existing functions, creation of unnecessarily complicated tools, and an error9
prone construction process. There are four categories of assumptions that lead to
architectural mismatch.
Nature of Components
This category is made up of three sub-categories: Infrastructure, Control Model and
Data Model. Infrastructure is the assumption regarding the additional infrastructure
that a component needs to provide or expects to use. Control Model assumptions are
those about which component holds the main thread of control. Assumptions about
the Data Model revolve around the nature and format of the data that a component
will be accessing.
Nature of Connectors
This category contains two sub-categories: assumptions about the communication
protocol between components and assumptions about the format of the communicated
data. A mismatch in either sub-category can lead to a substantial loss in performance.
A difference in the communication protocol might necessitate multiple connectors
between components; one for each protocol. Conflicting assumptions about the data
format would require a translation for each message passed between components.
Global Architectural Structure
Another class of assumptions that lead to architectural mismatch involves the global
architectural structure of the integrated components. For example, if a component
assumes that it is independent of other components while the architecture dictates
that components must cooperate and delegate tasks to other components, then there
are mismatched assumptions. In this case, any mechanisms that the first component
has to ensure its independence will be in conflict with the integration.
10
Construction Process
The final category contains assumptions about the code and the dependency structure of the code modules. Discrepancies would result in a complicated build process
in order to ensure that the dependencies of a component are available during compilation.
2.4
Analysis of Related Literature
The properties defined by Thomas and Nejmeh provide a precise set of principles to
guide the integration effort. In addition, the discussion of the event-based integration
approach provides a framework of the architectural integration that is applicable to
Palantı́r. The discussion of the problems that can arise will also guide the effort.
11
Chapter 3
Problem Statement
The original implementation of Palantı́r had an integration with three Configuration
Management systems: RCS, CVS and Subversion. These integrations are restricted
to the CM system. Thus, all other software development activities, including writing
the code, compiling, and debugging, must be done outside of Palantı́r. Although
Palantı́r is not necessarily concerned with these activities, combining then into one
environment would be extremely useful to the developer. Since the Eclipse platform
has facilities for all of these development activities as well as a Configuration Management interface, an integration of Palantı́r with Eclipse would address this issue.
However, the architecture of the Eclipse platform is much more complex than that of
a simple CM system. Therefore, the techniques used to integrate Palantı́r into RCS,
CVS and Subversion are not sufficient for an Eclipse integration. The aim of this
thesis is to examine this integration, implement it, and suggest any modifications or
improvements to the Palantı́r architecture.
12
Visualization(s)
Visualization(s)
Extractor
Extractor
Internal State
Internal State
Event Service
Event Wrapper
Event Wrapper
CM Client
CM Server
CM Client
Workspace
CM
Repository
Workspace
Figure 3.1: Palantı́r Architecture
3.1
Palantı́r Architecture
The original Palantı́r architecture is shown in Figure 3.1 [SNvdH03]. The arrows
represent the flow of information, the grey ovals represent typical configuration management components, and the white ovals represent the Palantı́r components. Each
of these components will be described below.
3.1.1
Event Wrapper
The event wrapper intercepts and interprets the activities in the Configuration Management workspace. If the activity is relevant to Palantı́r, the event wrapper collects the necessary information and constructs events that will be broadcast to other
Palantı́r clients. The commands and activities that each CM system provides and
produces are not uniform across the various systems. Since this component has a
13
Table 3.1: Palantı́r Events
Event
Populated
Unpopulated
Synchronized
ChangesInProgress
ChangesReverted
ChangesCommitted
Added
Removed
Renamed
Moved
SeverityChanged
Meaning
Artifact has been placed in a
workspace
Artifact has been removed from a
workspace
Artifact has been synchronized with
the repository
Artifact has been modified in the
workspace
Artifact has been returned to its
original state
New version of an artifact has been
committed to the repository
New artifact has been added to the
workspace
Artifact has been removed from the
workspace
Artifact has been renamed
Artifact has been moved
Severity value of an artifact has
changed
direct interface with the CM client, it is specific to the CM system used. However, it
does not affect the interaction that a user has with the system.
3.1.2
Event Service
The event service is responsible for distributing events to the Palantı́r clients. It is
implemented using the S iena event notification service [CRW01]. The events are
the basis of the Palantı́r data model. Each one represents the state of an artifact in
the workspace at any particular time. Components use information from these events
to perform their functions. Table 3.1 lists the events along with a brief description
of their meaning [SNvdH03].
14
3.1.3
Internal State
The internal state is responsible for maintaining a record of the activities in both the
local workspace as well as the workspaces of the other users. It subscribes to the
workspace activities that are relevant to the local workspace. The relevant activities
are defined as those that correspond to existing artifacts in the local workspace. The
internal state is also responsible for informing other workspaces of the existing content
in the local workspace. Because it uses the S iena events as its data, the internal state
component is independent of the Configuration Management system.
3.1.4
Extractor
The task of the extractor component is to filter the events that are displayed. Because
there can be many developers working in parallel, the Palantı́r visualizations can
become cluttered. The extractor allows the user to reduce the number of artifacts
in the display by allowing parameters to be selected that will only display desired
information.
3.1.5
Visualization
The visualization component organizes and displays the events in a format that is
suitable to the user. There are four different visualizations, each showing a particular
level of detail of the events.
15
The Eclipse Platform
Workbench
New Plug-in
Contribution
VCM
JFace
SWT
Workspace
Java
Development
Tools (JDT)
Platform Runtime
Figure 3.2: Eclipse Architecture
3.2
Eclipse Architecture
Figure 3.2 is a high-level diagram of the Eclipse architecture [Ecl04]. As shown,
Eclipse is essentially a tiny Platform Runtime kernel to which which all functionality
is contributed as a plug-in. It is not a monolithic application to which small pieces
of functionality are added. Every single tool, including the Java development tools
and the CVS repository functionality (VCM), is contributed. These contributions are
encapsulated in a plug-in, the smallest unit of Eclipse functionality.
Each plug-in contains one or more extensions and zero or more extension points.
An extension contains the implementation of the functionality that is being contributed. The implementation can contain Java code and other files. The optional
extension points allow other plug-ins to contribute additional functionality. For example, a plug-in that contributes a Java editor can declare an extension point that
16
allows another plug-in to contribute keyword-coloring to the editor.
The Eclipse platform is the common base to all Eclipse functionality. The platform
consists of several key components. These components are a subset of what is shown
in Figure 2. Each of these components will be described below.
3.2.1
Platform Runtime
The Eclipse Platform Runtime component starts the platform base, dynamically discovers the available plug-ins, and activates them when needed. In addition, it provides
the mechanism that allows Eclipse to be extended. Since the builders of Eclipse cannot anticipate the new features and services that will be contributed, this mechanism
is needed to maintain the stability of the API. Instead of permitting modifications to
the base interfaces of the Eclipse-provided types, the Platform Runtime component
allows behavior to be added by extending the interfaces of existing Eclipse types.
3.2.2
Workspace
The workspace component of the Eclipse architecture provides a user with access to
the relevant files and folders. This workspace maps directly to the underlying file
system, so users may modify resources directly on the file system or within Eclipse.
The Eclipse workspace has a hierarchical structure, with a workspace consisting of
projects, folders, and files. Each of these entities is termed a resource.
In order to track resources in the file system, Eclipse restricts access of the resource
to a handle. The handle acts as an abstraction or key to a resource. This allows a
resource to be accessed independent of its state.
17
3.2.3
SWT
The SWT component provides Eclipse with a common set of widgets, including buttons, menus, trees, and tables. It is designed to provide efficient, portable access
to the user-interface facilities of the operating systems on which it is implemented
[Ecl04]. To do this, SWT implements a thin layer on top of the operating system’s
native widgets. If a widget is not available, Eclipse implements it in Java.
3.2.4
JFace
The purpose of JFace is to provide higher level application support to complement
the functionality provided by SWT. There are several smaller frameworks contained
within JFace. These frameworks include viewers that convert Eclipse domain objects
into objects that can be presented in a view, contributions/actions that support user
events independent of the widget that triggered the event, dialogs and wizards that
provide higher level dialogs, and registries for images and fonts that manage the
resources of the user interface.
3.2.5
Workbench
The workbench component defines the Eclipse UI paradigm, including the editors,
views, and perspectives of the user interface. It builds upon the functionality provided
by SWT and JFace.
3.3
Eclipse Plug-in Creation
Eclipse has a very explicit process for creating a plug-in contribution. The elements
of the contribution must be declared in an XML manifest file. This file contains an
abstract description of the contribution, references the location of the implementation
of these elements, and lists the runtime dependencies. The abstract description of
18
the plug-in will contain a description of the functionality, including all user interface
elements. In order to extend Eclipse, the Platform Runtime component requires that
all contributions plug into a specific point in the platform which is termed an extension
point. All contributions must conform to a set of Eclipse interfaces that are specific
for that extension point. Once these interfaces are decided upon, the contribution is
implemented in Eclipse.
3.4
Analysis of the Architectures
The architectures of Palantı́r and Eclipse are complex. However, a few characteristics
of the architectures simplify the integration.
One of these characteristics is the modularity of the Palantı́r architecture. The
only component that is dependent on the Configuration Management client is the
Event Wrapper. Therefore, this is the only point that needs modification for the integration. The Event Wrapper can be modified to convert Eclipse workspace activities
into Palantı́r-specific events.
The plug-in architecture of the Eclipse platform will allow Palantı́r to be contributed as a plug-in. This will allow for the integration of the widgets and views
that encapsulate the Palantı́r functionality into the Eclipse user interface. Also, it
is not necessary to add any Configuration Management tools since a CVS repository
interface is provided by Eclipse.
19
Chapter 4
Approach
The approach to the integration of Palantı́r and Eclipse included the following steps.
First, the basics of the Eclipse open source architecture were learned, specifically the
semantics behind building an Eclipse plug-in and how it is used to extend Eclipse.
As mentioned earlier, the Platform Runtime component of Eclipse is responsible for
maintaining the stability of the platform. A technique that the Platform Runtime uses
is to require that all contributions conform to specific interfaces that Eclipse provides.
Before a plug-in for Palantı́r could be contributed to Eclipse, these interfaces needed
to be determined.
Since Palantı́r is concerned with activities in the repository, a determination
needed to be made about the way in which Palantı́r could access these activities.
The aim was to make the integrated version of Palantı́r independent from the repository. Therefore, the code of the Eclipse CVS repository was not modified. In addition,
the availability of a generic Eclipse Configuration Management repository API was
investigated. This would have ensured that the Palantı́r plug-in could work with all
Eclipse repositories.
Finally, the data provided by Eclipse needed to be converted to a form that
Palantı́r could understand. Since Palantı́r operates on S iena events while Eclipse
20
provides a resource data type, the necessary information was extracted from the
Eclipse resource to construct the S iena events.
21
Chapter 5
Implementation with a CVS
Repository
Although the architectures of Palantı́r and Eclipse are complex, integration of Palantı́r
into Eclipse seems relatively straightforward. The Event Wrapper must be modified
to intercept the activities of the Eclipse CVS repository, convert the Palantı́r visualizations into views in the Eclipse user interface, and encapsulate this in a plugin. Additionally, existing Eclipse facilities can be leveraged to add functionality to
Palantı́r.
5.1
Event Wrapper Modifications
The modifications to the Event Wrapper required three sub-steps. The first sub-step
was to start the Palantı́r application from the Eclipse workbench with the appropriate
artifacts for the visualizations. The original implementation requires that the user
checks out files from the repository into the workspace before the application starts.
However, in most development environments, including Eclipse, the developer might
not check out the artifacts very frequently. Instead, the developer might do a check
out once and enter a cycle of local modifications, updates, and commits before doing
22
another check out. During this cycle, the developer might also want to close the
Eclipse workbench. Palantı́r should not require that the developer do a check out
each time he or she opens Eclipse.
In order to address this issue, Palantı́r was modified to start with the active files in
the workbench that are under version control. If there are no such files, then Palantı́r
will wait until there is a check out. Since the Eclipse data model represents projects,
files, and folders as Eclipse-specific objects, accessor methods that are provided by
the Eclipse API were used to extract the necessary information from these objects in
order to construct the S iena events needed by the other Palantı́r components. This
conversion was necessary for all three sub-steps.
The second sub-step addressed the issue of intercepting the activities of the CVS
repository. In the original implementation, the event wrapper wrapped the command
line of the Configuration Management client, reading the input and output to and
from the repository. Thus, each integration of Palantı́r with a specific Configuration
Management system needed to be modified to handle the input and output for that
particular system. However, in Eclipse there is no command line interface to the
repository. The interface is contained within the repository plug-in. This plug-in
provides access to the repository and all relevant commands through the Eclipse
workbench. In order for the Palantı́r plug-in to follow the same design as the original
version of Palantı́r, the existing CVS repository plug-in would need to be modified
and bundled with the Palantı́r plug-in. Since a goal of the integration was to allow
Palantı́r to function with other repository plug-ins, the source code of the existing
CVS plug-in could not be modified.
Unfortunately, Eclipse does not provide a generic repository API. However, it does
provide a set of event listeners that trigger upon activities in the repository. Although
this will prevent the modification of the repository source code, the repository-specific
listeners must be referenced.
23
Beginning with Version 3.0, Milestone 6, Eclipse CVS included an event listener
interface termed the ITeamResourceChangedListener that was triggered each time
a resource under version control had a synchronization state change. These state
changes could be the result of a file being checked out, committed, added, or deleted,
or a project being disconnected from the repository. By extending this interface,
Palantı́r was able to listen for repository activities, process them when they occurred,
and extract the necessary information to create the S iena events. All of the necessary
information to construct the S iena events is contained within the information passed
to the listener.
The last sub-step of the Event Wrapper modifications was to include facilities
for detecting modifications in the local workspace. The original version of Palantı́r
relied on the developer to commit before it could determine if a change had occurred.
Because there could be many local modifications to an artifact between commits, it
is important to capture this information as well. Again, Eclipse provided an event
listener interface, termed IResourceChangeListener, which was notified when a local
save occurred. This interface was extended to collect the required information for
the S iena events. Additionally, Palantı́r is concerned with the time at which modifications of an artifact begin. Palantı́r differentiates between an artifact that has
been modified and one that is just checked out into the workspace. Thus, an event is
needed to broadcast that changes on an artifact are in progress. Eclipse also provides
workbench listeners that will catch these activities.
24
Visualization(s)
Visualization(s)
Extractor
Extractor
Internal State
Internal State
Event Service
Event Wrapper
Event Wrapper
Eclipse Event
Listeners
Eclipse Event
Listeners
Eclipse
Workspace
Eclipse
Workspace
The Eclipse Platform
Eclipse CM Client
Eclipse CM Client
CM Server
CM
Repository
Figure 5.1: Architecture of the Palantı́r/Eclipse Integration
Figure 5.1 illustrates the new architecture of the Palantı́r/Eclipse integration.
Again, the arrows represent the flow of information. All of the components of the
Palantı́r architecture and the Configuration Management system are intact. However, the interface between Palantı́r and the Configuration Management system has
changed to Eclipse components. The Event Wrapper no longer wraps the CM Client
as it does in the original architecture shown in Figure 3.1. As detailed in the original section, the Event Wrapper registers for and receives information about local
workspace activities and repository activities from Eclipse event listeners.
25
5.2
Conversion
of
Palantı́r
Visualizations
to
Eclipse Views
When deciding how to integrate the Palantı́r visualizations into the Eclipse user
interface, a realization was made that there was a mismatch between the user interface components of the architectures; they use different toolkits for their widgets.
The Eclipse UI is implemented using SWT while the Palantı́r visualizations are implemented using Swing/AWT. Since there is no direct translation between the two
toolkits, an Eclipse view containing the Palantı́r visualizations could not be created
without modifications to the source code of the visualization.
Initially, the focus was on integrating the Event Wrapper, leaving the Palantı́r
visualizations as they were. This allowed the underlying functionality to be completed
while still seeing the visualizations outside of Eclipse.
26
Figure 5.2: Screenshot of the Impact and Severity Triangles
Next, the possibility of adding bits of Palantı́r functionality into the existing
Eclipse views was examined. The Navigator view in Eclipse displays the hierarchy of
folders and files in the projects. Decorators were affixed to the resources in the view
to denote severity and change impact, two calculations done by Palantı́r [SNvdH03].
The decorators were in the form of triangles that were overlaid on the resource.
Figure 5.2 is a screenshot of showing the decorators. The red triangles represent
the severity while the blue triangles represent the impact. A change in these values
results in a change in the size and darkness of the triangles. The higher the value,
the larger and darker the triangles become. Following the name of the resource, there
are numbers indicating the actual values of the severity and change impact. Since
space constraints within the view limited the number of severity and impact values
that could be displayed, only the average value across all workspaces, not including
the local workspace, is shown.
Finally, the issue of integrating the Palantı́r visualizations into the Eclipse workbench was addressed. There exists an open source Java library called SwingWT
27
that provides functionality to wrap SWT widgets around Swing/AWT widgets, allowing applications written with Swing/AWT to be compatible with Eclipse [RT04].
Unfortunately, the SwingWT API does not contain a complete set of AWT widget
functionality that is necessary to create the Palantı́r visualizations as Eclipse views.
Thus, the integrated version of Palantı́r continues to use the same visualizations as
the original version.
28
Chapter 6
Implementation with a Subversion
Repository
In addition to the CVS repository plug-in, there is also an Eclipse plug-in for a
Subversion repository called Subclipse. Although out of the scope of this thesis, it
is important to understand how the Palantı́r plug-in would be implemented using
Subclipse. Since there is not a generic repository API available for use by Palantı́r, a
separate plug-in must be implemented for a Subversion repository.
Similar to the CVS plug-in, Subclipse has a listener that will monitor activities
in the repository. Subclipse terms its listener an IResourceStateChangeListener. By
extending this listener, activities in the repository can be caught and processed. A
difficulty arises with the information that is passed to the listener. In the CVS
listener, all of the information that is necessary to create the various S iena events
is available. This is not the case for the Subclipse listener. It only provides an
array of resource objects for the resources that have changed. In order to glean the
necessary information from these resources, the objects need to be cast into a specific
Subclipse-specific resource object and use the accessor methods for that object.
The listeners that monitor activities in the local workspace can remain the same for
29
Subclipse since these are from the Eclipse workbench, not the particular Configuration
Management repository.
30
Chapter 7
Validation Plan
The final step of this thesis was to validate the results of the integration. There were
two parts to the validation plan. The first part was to use the integrated tool in
a small-scale software development scenario. The purpose of this was to make sure
that all of the functionality of Palantı́r was captured in the Eclipse integration. In the
second part, the integration was analyzed with respect to the principles of Thomas
and Nejmeh that were outlined in the Literature Review.
7.1
Example Development Scenario
In order to ensure that the Eclipse version of Palantı́r included all of the functionality of the original version, the integrated tool was used in a software development
scenario. Because it was necessary for the subjects to be familiar with the original
version of Palantı́r, the four developer/students in the Palantı́r development team
were gathered to participate. Although each person was heavily involved in the development of Palantı́r and had an interest in its success, bias was not a concern since
the verification was only that the Eclipse version behaved in the same way as the
original version, not making a statement about the usefulness of the tool itself.
The tool was used within the Palantı́r team to improve the tool itself. The re31
quired work was distributed among the four developers. One person was tasked to
make modifications to the visualizations and add a new visualization. Another person examined new ways to do the calculations for severity and change impact. The
third person was in charge of creating a database for storing the events. The fourth
person was trying to improve the event mechanism. Each person checked out the files
at the same point and began the cycle of making modifications, updating their local
copies so they are synchronized with the repository, and committing their modifications. During this process, there were no noticeable differences in the visualizations
compared to the original version, nor were there any errors in the information that
was displayed.
7.2
Verification of the Integration
The example scenario verified that the integration of Palantı́r in Eclipse was successful
in that all the functionality of the original version of Palantı́r was captured. However,
it was also important that the two architectures were well-integrated with respect to
the principles outlined by Thomas and Nejmeh [TN92]. There were two properties
that the integration deviated from. Issues with the user interface implementations
resulted in an inconsistent Presentation paradigm and minor transformations were
needed to integrate the tools with respect to the Data property. Each property is
listed here with specifics to the integration.
7.2.1
Presentation
The goal of this property is to improve the efficiency and effectiveness of the user’s
interaction by reducing the cognitive load. This was not achieved in the integration.
Because of the incompatibility of the user interface implementations, the integration
uses two interaction and presentation paradigms: Eclipse views and Palantı́r visual32
izations.
The presentation property would have been achieved if the Palantı́r visualizations
were converted into Eclipse views. The result would be an Eclipse interaction and
presentation paradigm for the integration. Since Eclipse forces a contribution to
conform to its rules of presentation and interaction, the Palantı́r plug-in would be
implemented according to these rules. This includes the way the visualizations appear
and behave through Eclipse views.
However, the integration did succeed in several respects of the Presentation property. The plug-in produced the same information in the same amount of time as the
original version, matching the user’s expectations for response time and the information produced by Palantı́r was preserved in the integrated version.
7.2.2
Data
The goal of the Data property is to ensure that the information in the environment
is managed as a consistent whole. The sub-properties are interoperability, nonredundancy, data consistency, data exchange, and synchronization.
With respect to data interoperability, the integration did not fulfill the principles
of Thomas and Nejmeh [TN92]. Since Palantı́r operates on S iena events, it could
not be modified to directly use Eclipse data. Instead the Eclipse-specific types were
converted to S iena events. However, this was a simple transformation, using the
provided methods in the Eclipse API.
Nonredundancy was not addressed. Since each tool operates on different data
types, they need to store their own version of the data for each artifact.
Data consistency was a property that was fulfilled. Since Palantı́r does not modify
Eclipse data and the changes to artifacts in Eclipse are propagated to Palantı́r through
the event notifications, mechanisms to keep the data consistent are already provided.
Similar to the interoperability property, the integration also required transforma33
tions to the non-persistent data. According to the principles, Palantı́r and Eclipse
are not well-integrated with respect to this property.
The synchronization property was also fulfilled in the same manner that the data
consistency property was fulfilled. Changes to Eclipse data are communicated to
Palantı́r through the event notification mechanism.
7.2.3
Control
For the Control property, the goal is to allow the flexible combination of the environment’s function by addressing control-transfer and service-sharing issues. The
provision and use sub-properties were both fulfilled since Eclipse provides all the necessary functionality to Palantı́r and Palantı́r uses the services of Eclipse to perform
its duty.
7.2.4
Process
In order to ensure that the tools interact effectively in support of a defined process,
the expectations of the Process property must be met. This was accomplished by the
integration. The process step, displaying Palantı́r information, can be decomposed
into two steps: Eclipse discovering a change to an artifact and notifying Palantı́r, and
Palantı́r interpreting this data and displaying it. The process event sub-property is
also fulfilled with the event mechanism used in the integration. The expectations of
the process constraint sub-property are not applicable since Palantı́r does not impose
any constraints on the environment.
34
Chapter 8
Analysis of the Integration
In addition to validating the integration in the example scenario and applying the
rules set forth by Thomas and Nejmeh [TN92], the successfulness of it with respect
to the initial expectations of the integration was examined. Possible improvements
to Eclipse and Palantı́r were also explored.
Overall, the integration was a success in that a Palantı́r plug-in was contributed
to the Eclipse platform. This plug-in included all of the functionality of the original
version of Palantı́r. Furthermore, the ability to process local workspace modifications
was added to the existing functionality of Palantı́r.
However, there were parts of the integration that did not meet the initial expectations. One of the goals was to fully integrate the original Palantı́r visualizations into
Eclipse views. Because of the incompatibility of the Eclipse user interface components with the Palantı́r user interface components, a complete rewrite of the Palantı́r
visualizations would be needed to convert them to views in Eclipse.
Another expectation was that the Palantı́r plug-in would be completely independent from the Configuration Management repository. This would allow Palantı́r to be
used in Eclipse regardless of the type of repository used. Unfortunately, the current
Eclipse API did not allow for this. Instead of providing a generic repository API that
35
each repository must conform to, Eclipse allowed each repository to be implemented
in any fashion. In order to implement the necessary listeners for Palantı́r, a separate
plug-in is needed for each type of repository.
Although there are no major improvements needed to either architecture, a few
minor enhancements could be made to the implementation of both tools. Facilities
that would allow user interface elements that are not implemented in SWT to be used
in Eclipse would be useful. Since many Java applications are built with Swing/AWT,
there would be a great benefit to including functionality for this conversion.
In addition, including a generic repository API would be extremely beneficial.
This would require that repository implementers would have to conform to a more
complete set of rules to access a repository in Eclipse. By requiring that a stricter set
of rules is followed, a generic repository API would also help with maintaining the
stability of the platform.
There was an issue was encountered with Palantı́r. In many cases, it seemed that
the S iena event mechanisms were not able to handle the events effectively. Dropped
events and out of order events were common enough to be a concern. There are two
potential modifications to explore. The first is to make Palantı́r robust enough to
handle the problems in the event mechanism, as the current implementation does not
account for problems in the events. The second potential modification is to abandon
the S iena event notification service entirely, instead relying on the event mechanisms
that are built into Eclipse. Although this would address the issues and remove the
need to perform transformations on the data between the tools, it would be quite
different than the original implementation of Palantı́r. Since the original versions are
still being used and developed, the implementations should be kept as consistent as
possible.
36
Chapter 9
Conclusion
In this thesis, the integration of Palantı́r into the Eclipse open source platform was
examined. This included a discussion of a few general issues in architectural integration, a description of the implementation of the integration, and a discussion of
a few improvements made in the functionality of Palantı́r. More specifically, this
thesis contributes a new integration of Palantı́r in Eclipse. By combining Palantı́r
with the rich functionality of Eclipse, a Configuration Management awareness tool is
now available for the platform. In this setting, Palantı́r can leverage the additional
tools that Eclipse provides and capture activities that are outside of the Configuration Management repository; something that the original version of Palantr was not
able to do. Also, Palantı́r functionality has been added directly on top of the existing Navigator view in Eclipse. This will provide some quick awareness information,
without having to constantly refer to the Palantı́r visualizations.
Despite the complexity of both architectures, the plug-in architecture of Eclipse
made the integration very straightforward. This architecture inherently addressed
most of the properties of a sound integration.
Future work on the integration includes exploring other ways of displaying Palantı́r
information in the Eclipse views, examining the current visualizations in order to
37
ensure that the information that they provide is still useful in the Eclipse setting,
developing new visualizations, and optimizing the event notification mechanisms. In
addition, the integrated tool should be used in an actual development environment.
Finally, publishing the plug-in in the open source community will hopefully increase
its exposure, and provide us with feedback on how to improve Palantı́r.
38
Bibliography
[BCTW96] Daniel J. Barrett, Lori A. Clarke, Peri L. Tarr, and Alexander E. Wise.
A framework for event-based software integration. ACM Transactions on
Software Engineering and Methodology, 5(4):378–421, 1996.
[Bro95]
Frederick P. Brooks. The Mythical Man-Month. Addison-Wesley, second
edition, 1995.
[CRW01]
Antonio Carzaniga, David S. Rosenblum, and Alexander L. Wolf. Design
and evaluation of a wide-area event notification service. ACM Transactions on Computer Systems, 19(3):332–383, 2001.
[Ecl04]
Eclipse Foundation. eclipse.org. http://www.eclipse.org, 2004.
[GAO95]
David Garlan, Robert Allen, and John Ockerbloom. Architectural mismatch: Why reuse is so hard. IEEE Software, 12(6):17–26, 1995.
[RT04]
R. Rawson-Tetley. SwingWT. http://swingwt.sourceforge.net, 2004.
[SNvdH03] Anita Sarma, Zahra Noroozi, and André van der Hoek. Palantı́r: Raising
awareness among configuration management workspaces. In Proceedings
of the 25th International Conference on Software Engineering, pages 444–
454, Portland, Oregon, 2003.
[TN92]
Ian Thomas and Brian A. Nejmeh. Definitions of tool integrations for
environments. IEEE Software, 9(2):29–35, 1992.
39
[Was90]
Anthony I. Wasserman. Tool integration in software engineering environments. In Proceedings of the international workshop on environments
on Software engineering environments, pages 137–149, Chinon, France,
1990.
40