Collaborative Eclipse Plug-in

Integration Architecture for stand alone programs (agents)

A project Report Summary

By

Shajil K Kalathil (04/29/2005)

Table of Contents

1. Eclipse Platform Overview................................................................ 3 2. Eclipse Cross Section ........................................................................ 3 3. Eclipse Building blocks – Plug-ins.................................................... 4 4. Platform Runtime and Plug-ins.......................................................... 4 5. CIS 5015 Motivation ......................................................................... 6 6. Gap Analysis...................................................................................... 8 7. Agent Integration Architecture .......................................................... 9 7.1. Static Class Diagram - General....................................................... 9 7.2. Static Class Diagram – FtcAnalyzer ............................................. 10 7.3. Sequence Diagram........................................................................ 10 7.4. Agent Lifecycle ............................................................................ 11 8. Critical Architectural Changes......................................................... 12 9. Project Development ....................................................................... 12 9.1. Project Risks ................................................................................. 12 9.1.1. Technological Risks................................................................... 12 9.1.2. Infrastructure Risks.................................................................... 13 9.1.3. People Risks............................................................................... 13 9.1.4. Eclipse – Commercial Interest Risks ......................................... 14 9.1.5. Agent Integrator Risks............................................................... 14 9.2. Program / Agent Integration Achievements ................................. 14 9.3. Future Direction (new agents) ...................................................... 15 10. Web Site Tour............................................................................... 15 10.1. Major Lessons Learned.............................................................. 16 11. Conclusion .................................................................................... 17 12. References .................................................................................... 17

1. Eclipse Platform Overview The Eclipse Platform is designed for building integrated development environments (IDE) that can be used to create applications targeting a wide domain such as web application, embedded Java programs, Java Mobile programs, C++ programs, and Enterprise JavaBeans. It is an open, extensible architecture based on plug-ins.

The Eclipse Platform is designed and built to meet the following requirements:

• Support the construction of a variety of tools for application development. • Support an unrestricted set of tool providers, including independent software

vendors • Support tools to manipulate arbitrary content types (e.g., HTML, Java, and C). • Facilitate seamless integration of tools within and across different content

types. • Support both GUI and non-GUI-based application development environments. • Run on a wide range of operating systems

The Eclipse has a highly scalable architecture which helps to integrate various tools in eclipse using the established eclipse API. These mechanisms are exposed via well-defined API interfaces, classes, and methods. The Platform also provides useful building blocks and frameworks that facilitate developing new tools.

2. Eclipse Cross Section

Figure 1

Java VM Standard Java2 Virtual Machine

Platform Eclipse Platform

Java development tools

JDT

PDE Plug-in developmentenvironment

3. Eclipse Building blocks – Plug-ins

Figure 2

4. Platform Runtime and Plug-ins

A plug-in is the smallest unit of Eclipse Platform function that can be developed and delivered separately. Usually a small tool is written as a single plug-in, whereas a complex tool may inherit the functionality from many different small plug-ins. Plug-ins are coded in Java. A typical plug-in consists of Java code in a JAR library, some read-only files, and other resources such as images located in icon directory, native code libraries, etc. It is also possible that some plug-ins may not contain code at all. Each plug-in has a manifest file (xml) declaring its interconnections to other plug-ins. The interconnection model is such a way that a plug-in can declare any number of extension points, and any number of extensions to one or more extension points in other plug-ins. A plug-in’s extension points 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.

Sample of Manifest file written for CIS- DtcAgent

Platform Runtime

Eclipse Platform

Workspace

Workbench

SWTJFace

Team Help Debug

Ant“Core

“UI

<?xml version="1.0" encoding="UTF-8"?> <?eclipse version="3.0"?> <plugin id="DtcAgent" name="DtcAgent Plug-in" version="1.0.0" provider-name="Kehil Wright" class="dtcAgent.DtcAgentPlugin"> <runtime> <library name="DtcAgent.jar"> <export name="*"/> </library> </runtime> <requires> <import plugin="org.eclipse.ui"/> <import plugin="org.eclipse.core.runtime"/> </requires> <extension point="org.eclipse.ui.actionSets"> <actionSet label="Dtc Agent Action Set" visible="true" id="dtcAgent.actionSet"> <menu label="Agent &amp;Menu" id="agentMenu"> <separator name="agentGroup"> </separator> </menu> <action toolbarPath="agentGroup" label="Dtc Action" tooltip="A decision Table Creator " class="dtcAgent.actions.DtcAction" icon="icons/agent.gif" menubarPath="agentMenu/agentGroup" id="dtcAgent.actions.DtcAction"> </action> </actionSet> </extension> </plugin>

Required Plug-ins Library

Location of Plug-ins code

Declare contribution this plug-in makes

Declare action and menu contribution

5. CIS 5015 Motivation

Dr Edward Jones –chair CIS department has been guiding many graduate and undergraduate students in developing standalone projects as part of research and also as part of thesis required for graduate students. Presently CIS has a rich library of evolving projects. These projects are getting developed as a part of corrective, preventive and adaptive maintenance. These include

1. Boundary Test Value Generator – Sheetal Kottayi 2. Path Coverage Analyzer – Shajil K Kalathil 3. JTeg Parser – Mike Ayodale 4. Function Test Coverage Analyzer – Melissa Clark 5. Tgen – Junit Jasmeet and Bala 6. Decision Table creator – Kehil Wright.

All these projects cater a specific functionality. Let us say for example Boundary test Generator generates boundary values from a given decision table. (proj 1). Decision Table creator creates the Decision table (proj 6). Funcion Test Coverage reads Decision table and creates testable specification program (proj 5). Let us just analyze this for a moment. Individually these projects (say agents) are powerful in executing a single task. Dr Jones’s vision is about extending this individual power and bring a synergy by making many agents participate in a collaborative environment. Considering this we can realign the fore mentioned three projects and we may get a collaborative environment as mentioned in the following figure 3

Collaborative Agent Communication

Uses

Figure 3

Eclipse provides an easily pluggable architecture wherein all these individual projects can be plugged. It also facilitates the inter communication of plug-ins through the extension points mentioned in plug-in manifest file. Eclipse architecture’s support of multi language operability helps in this communication irrespective of which language they are written. In the above example BTV, FTC are C++ projects and DT creator is a java program. The interconnection technology is explained in figure 4.

Multi – Agent (plug-in) Communication Frame Work

Platform Runtime

Workspace

Help

Team

Workbench

JFace

SWT

Eclipse Project

JavaDevelopment

Tools(JDT)

Tgen Junit (Jasmeet

Jtegoo Agent (mike)

DtcAgent(KWrightl)

Plug-inDevelopmentEnvironment

(PDE)

Eclipse Platform

Debug

FtcAnalyzer (Clark)

Figure 4

6. Gap Analysis

To integrate the above mentioned projects we need to understand in detail how eclipse architecture works and how plug-ins are able to communicate. We conducted extensive study of this architecture. Since the CIS projects are of varying nature, a gap analysis was conducted to better understand the application. The following projects were considered for Gap Analysis.

6.1.JTegoo Project 6.2.JTegparser Project 6.3.DTCreator Project 6.4.Tgen- Junit 6.5.FTC analyzer.

On a detailed requirement analysis it was found that the 6.1, 6.2, 6.3 were of similar nature where in they needed user input through the user interface. All these projects were written in java and had a main method which was the starting point of execution. Further we found that it would be appropriate to provide a Menu group called “Agent Group” and provide a button for each of these agents by clicking on which will start the execution of the program / agent. FtcAnalyzer posed a major challenge since it was written in C++ and had high coupling with Unix operating system using system calls. We decided to simulate the development of C++ FtcAnalyzer using the following environment MinGW v3.0.0-1 Eclipse CDT plug-in. At first we decided to use Java JNI (Java native interface) wrapper for a given C++ project. JNI interface helps in wrapping the complete C++ program through method calls. After researching on this topic, we were unable to make progress on Native Method call on windows operating system due to “Unsatisfied Link Error”. Since the project did not need user interaction and due to JNI native call problems, Dr Jones suggested executing the same as a batch job. This came handy due to limited time constraints but needed a different custom plug-in which will be able to execute the job. A detailed article of how to integrate a C++ complier and develop C++ project is explained on my web site. Please refer http://www.cis.famu.edu/~skalathil/presenations/7-EclipseCDT.pdf

.

7. Agent Integration Architecture

7.1. Static Class Diagram - General

A detailed static diagram is mentioned in Figure 5. This static diagram is in general and is taken from the one created for DTCAgentPlugin for the explanation purpose. DecTbl – The user defined class for executing Decision Table. This class has a method called startDecTbl(). Eclipse invokes this method to start the agent. AbstactAgent – An interface with three method calls. Start(), stop() and run(). AgentRunner – This class implements AbstaractAgent and Inherits from user defined class. This was an enhancement done so that no user defined classes had to be changed to incorporate into eclipse.

DtcAction – This class extends from WorkBenchWindowActionDelage. Eclipse invokes this agent by calling start() method of this class.

Static Class Diagram -Agent Architecture

Figure 5

7.2. Static Class Diagram – FtcAnalyzer

Unlike Other agents FtcAnalyzer needed a custom change to support the invocation of binary executable. FtcAnalyzer is a java class which wraps the FtcAnalyzer C++ binary. This class upon invocation creates a new java process and executes the binary. Code snippet for the same is given below.

Figure 6

7.3. Sequence Diagram

The object sequence diagram for the agent architecture is described in Figure 6.

When DtcAction button from menu is clicked eclipse invokes DtcAction start method via delegation. The detail of how this Action is invoked is not explained here but may be found on eclipse site under the topic “Contributing to Menu bar” DtcAction calls start() method. In this action a reference to DecTbl is obtained via Polymorphism and dynamic binding properties of object orientation. AbstarctAgent->AgentRunner->DecTbl

Object Sequence Diagram -Agent Architecture

Figure 6

7.4. Agent Lifecycle

When eclipse starts, not all the plug-ins are loaded. Plug-ins are loaded lazily. Which means from an operating efficiency point, plug-ins will be loaded only when they are called except for core plug-ins? Every agent goes through the following lifecycles. When the stop method is invoked the plug-in is released from the dynamic cache.

8. Critical Architectural Changes

Initially it was thought that, up on completion of the plugin frame work some customization of the individual agent was needed for getting integrated. This approach changed due to the fact that individual project completion was getting delayed and integration testing was getting delayed even further. This constraint evolved into a new architecture such that with the help of a new class “AgentRunner” no custom change was required for individual plug-ins. Agent Architecture inherits from the stand alone agent and implements the super interface “AbstaractAgent”. Up on invocation of the plugin button messages are passed using Object oriented behavior of polymorphism and dynamic binding. This helped in doing the integration testing using stand alone agent simulation (prototype).

9. Project Development

9.1. Project Risks

This project was undertaken to architect a frame work using Eclipse IDE where in every one can contribute their project as a Plug-in. This is relatively a new concept and it has its own risk and uncertainties. I have a very good understanding of Eclipse IDE as a user, but not as an eclipse developer who needs to deal with eclipse core kernels. When I was assigned the role of an Architect, I identified major potential risk categories.

9.1.1. Technological Risks Problem In programming language, such as java or c++ it may be possible to get help from experts. Eclipses being a relatively new subject not many experts were available for working with core internals. This was identified as a major risk Impact Unable to proceed in getting a plug-in executed. Eclipse was able to find the class statically, but not at runtime Risk Mitigation Books written by Eclipse Core team members were made available. Registered in Eclipse Forums Decided to devote an hour a day in reading technical articles about eclipse project kernels.

9.1.2. Infrastructure Risks

Problem Since the project was to create a collaborative environment where in every one’s project can be plugged, I needed a system with sys admin capabilities. Requests were made to System Admin professionals but nothing concrete has happened. I was sure that this may become potential risk since I had a similar experience in a previous project. Impact I was unable to develop plug-in frame work for more than one plug-in since the inter operability was uncertain Risk Mitigation Dedicated my home personal computer exclusively for Eclipse project. Installed the latest Eclipse plug-in ide and all required plug-ins. Continued developing plug-in for CIS 5015 spring 2005 projects.

9.1.3. People Risks Problem The true success of my architecture lies in the ability to demonstrate the stake holders how individual plug-ins can be plugged. First I proceeded with the approach that, I will create the frame work and when individual project members are ready I will start the testing. The risk was what if the project members could not finish the project in time? Impact Project members were unable to make a smooth sailing in individual projects due to many reasons beyond their control. Individual project were not delivered in time. Risk Mitigation After waiting till April 15, 2005, I decided to create a prototype for each project. My architecture was already completed. I created the first prototype for Decision Table Generator. This made me realize the difficulties involved in getting a single plug-in to work. I refined my architecture to include an agent runner so that stake holder’s code remains untouched. When I got the prototype to work I integrated Jteg parser plug-in and Mike’s JTegoo plug-in and so on. The key achievement was that, had I not developed those

prototypes I would not be able to complete till today and it would have been last moment rush.

9.1.4. Eclipse – Commercial Interest Risks

Problem The API is tightly held by IBM. API access is limited IDE world is spilt between netbeans and eclipse. Eclipse forum is new and maturing Operating system centric on the presentation layer Risk Mitigation plan Develop plug-ins such that they do not use SWT interface. Eclipse developers should register in forums and in eclipse and source forge for getting acclimatized with the eclipse, development.

9.1.5. Agent Integrator Risks

Problem Students may not be able to develop the agents in time. Risk Mitigation plan Create a base architecture Understand Hand-shake points Create interface so that parallel development can be done. If projects are further delayed request the developers to create a demo prototype

9.2. Program / Agent Integration Achievements Agent Developer Current Status Remarks Jtegoo Mike

Ayodale Integrated Integrated with Button

Click JTegParser Mike

Ayodale Integrated Integrated with Button

Click DtcAction Kehil

Wright Integrated the Working Sample

Need to complete the project with ability to create DTC.

Tgen Junit Jasmeet Integrated with Jasmeet needs to complete

Sachdeva Source code selection by right click.

the Test Driver class to be able to read the Java class with package name.

FtcAntalizer

Melissa Clark

Integrated with a prototype.

The prototype name need to be changed in FtcAnalyzer.java class to point the path of the Binary when project is completed

9.3. Future Direction (new agents)

• Agent for repository submission from eclipse • Agent for web-service. • Admin agent for administering the servers • Inter-eclipse agent communication • Path Coverage Analyzer Agent • Boundary Test Generator Agent • Mobile Computing Agent • Agent manager – to manage other agents

10. Web Site Tour

Please visit the website http://serel.cis.famu.edu/~skalathil/ for the details of collaborative frame work architecture and for downloading the agents.

You may download each of the agents by clicking on the links shown at the left top of the screen. It also provides links for the detail architecture and design documents

10.1. Major Lessons Learned

If there is a task to do, never delay it. Have a contingency plan from day one. Use repository for software development. Baseline when a major mile stones are achieved / release to be done. You can control only what you know. Unknown is infinite. Learning is the only tool to eliminate the gap (known vs. unknown) Never, never give up. There is a light at the end of the tunnel. Believe in the end being near. Always have a positive attitude

11. Conclusion

This has been a challenging project. A full blown integration agent model is created. While individual agents can continue working as stand alone, it is also possible to harness the synergy using the collaborative approach. The project is base lined and a copy of all artifacts is submitted to the repository. One may find a readme.txt which has all the instructions for how the files are stored. Each plug-ins is stored as jar file which may either obtained from the repository or from the web site.

12. References 12.1. Eclipse Distilled (Eclipse)

by David Carlson; Publisher: Addison-Wesley Professional; Paperback 12.2. Eclipse: Building Commercial-Quality Plug-ins (Eclipse Series)

by Eric Clayberg, Dan Rubel; Publisher: Addison-Wesley Professional; Paperback

12.3. Eclipse Modeling Framework (The Eclipse Series) by Frank Budinsky, David Steinberg, Ed Merks, Raymond Ellersick, Timothy J. Grose; Publisher: Addison-Wesley Professional; Paperback

12.4. Eclipse in Action: A Guide for the Java Developer by David Gallardo, Ed Burnette, Robert McGovern; Publisher: Manning

12.5. http://www.eclipse.org 12.6. http://www.sun.com 12.7. http://www.javasoft.com