Technology

Migration of Eclipse based products :- Need of time

2010-04-05T01:05:00.001-07:00

Introduction
This paper is intended to describe newer features of Eclipse and Eclipse based projects. Paper also describes why one should migrate from older Eclipse runtime to newer one. To explain these points, I will be taking example of our team which is doing migration of our product from Eclipse 3.2 to Eclipse 3.5 runtime.
Motivation
From past three year, our team is working on Eclipse based RCP product. This product has been built on older version of eclipse. Runtime for our product is based on Equinox 3.2, which is implementation of OSGi R4 core framework specification. Our project uses lot of Eclipse based projects, such as EMF, GEF, GMF, etc. All these project plug-in sets are based on Eclipse 3.2 runtime.
Few days back we have decided to migrate our product to Eclipse 3.5 runtime. Before making this decision, we had lot of discussions on migration. We have discussed pros and cons of migration. At one end we could see all the good features of newer Eclipse and at other end changes we might have to make lot of changes in our product. Finally after lot of debate, we have started migration process. Basic motivation behind the migration is “Newer Features provided by Eclipse 3.5”. This paper intended to document reason behind our motivation. In other words, this paper will explain “What's new in Eclipse 3.5”. Please remember that I am not just focusing on Eclipse 3.5 but I will be also covering some Eclipse based projects which we used in our product.
Background
Before going into details of Galileo's (Eclipse 3.5) features, I would like to describe what eclipse is in short. Definition of Eclipse popularly known to everyone is “Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system”. But I personally like other definition of Eclipse, and which is “Eclipse is framework for everything and nothing in particular”.
Most software developer knows that Eclipse is a popular Integrated Development Environment (IDE) for Java. As Eclipse is free and stable, lot of programmers now a days are using Eclipse as an IDE. It is written primarily in Java and can be used to develop applications in Java and, by means of the various plug-ins, in other languages as well, including C, C++, COBOL, Python, Perl, PHP, and others. The IDE is often called Eclipse ADT for Ada, Eclipse CDT for C, Eclipse JDT for Java and Eclipse PDT for PHP.
Eclipse began as an IBM Canada project. It was developed by Object Technology International (OTI) as a Java-based replacement for the Smalltalk based VisualAge family of IDE products, which itself had been developed by OTI. In November 2001, a consortium was formed to further the development of Eclipse as open source. In January 2004, the Eclipse Foundation was created. Eclipse was originally released under the Common Public License, but was later relicensed under the Eclipse Public License.
Most people think that Eclipse is only a Java IDE, but it's not just an IDE, it is complete framework. It is based upon OSGi (Open Service Gateway initiative) standard. This standard defines specification for creating component based architecture over java runtime environment. Eclipse has implemented OSGi specification using Equinox project. Eclipse supports plug-n-play architecture and it allows bundle or plug-in to load on demand. In programmer's jargon, it is called as lazy loading.
There are lots of project build over Eclipse platform. Most popular projects are EMF (Eclipse Modeling Framework), GEF (Graphical Editing Framework), BIRT (Business Intelligence and Reporting Tools), etc. All development toolkit, such as Java Development Toolkit (JDT), PHP Development Toolkit (PDT), C/C++ Development Toolkit (CDT), etc is also based on eclipse framework.
So remember Eclipse is not just an IDE, but it is framework containing some built in tools.
Drivers for moving to Eclipse 3.5 :
As our older product was on Eclipse 3.2 runtime, we faced some limitation while implementing new features.
a) User Interface:
For development of basic user interfaces, we were using SWT 3.2. SWT (Standard Widget Toolkit) is cross-platform graphical widget toolkit for use with the Java platform. In newer SWT versions, eclipse has improved / added lots of user interface component. Improved StyledText widget, new system tray support, new Date widget, improved color schemes, new line drawing capabilities, effective drag-n-drop, effective browser support, improved copy paste support, etc are just some instances of improvement in SWT. In these three years lot of SWT APIs are changed for providing better control. Apart from these UI changes, SWT has improved lot on platform portability. Now SWT runs perfectly on newer Windows OS (operating system) versions, Linux, Mac OS, Solaris, HP-UX, etc. Now SWT runs on almost all bits of operating systems.
Eclipse has developed a framework called JFace on top of SWT. JFace is a UI toolkit that provides helper classes for developing UI features that can be tedious to implement. It is a layer that sits on top of the raw widget system, and provides classes for handling common UI programming tasks. It brings model view controller programming to the Standard Widget Toolkit (SWT). As the underline SWT widgets have improved, JFace is able to extract better support from SWT. Improvement in SWT leads to improvement in JFace.
Eclipse workbench is built up using SWT. Using newer version of SWT, Eclipse has improved workbench's look and feel. So by using newer graphical plug-ins of Eclipse, we are able to improve the look and feel of our application.
Migrating our product to newer Eclipse Runtime, user interface of product has improved. Also due to use of new graphical library, we can implement newer widgets and improve existing user interface.
b) Restricted upgrade support:
Eclipse 3.2 was using Upgrade manager to upgrade eclipse plug-ins. Upgrade manager was also used for installing new plug-ins. In newer versions, Eclipse has come up with a new way for upgrading and installing plug-ins, which is called as p2. P2 stands for Provisioning Platform. Provisioning is a process of providing users with access to data and technology resources. The term typically is used in reference to enterprise-level resource management. P2 replaces the upgrade manager with simplified workflows. So it will be a lot easier to install new plug-ins and keep them managed. P2 also comes with concept of 'Bundle Pooling'. That means you can share plug-ins across multiple Eclipse instances. By using Bundle Pooling, you can reduce considerable amount memory and disk space. P2 automatically find out all the dependent plug-ins for running particular functionality and installed those automatically.
So by incorporating p2 in our product, we can provide better support for upgrade. Philosophy behind p2 project was, user should not install-uninstall eclipse multiple times, user should only upgrade existing eclipse. We wanted to have same principle in our product.
c) Incompatible newer plug-ins:
Eclipse 3.2 has been released in the June 2006. It was just third release of Eclipse using OSGi specifications. Now after three years Eclipse has come long way. In year 2007-08 Eclipse got lot of popularity. Lots of enhancement has been done in Eclipse. Lots of new project has been started in Eclipse Release Train. For example, Mylyn, BIRT, Eclipse RT, etc. Now a day’s Eclipse comes in lot of flavors such as Eclipse for J2EE, Eclipse for PHP development, Eclipse for Mobile platform(Pulsar), etc. Most of the newer projects or frameworks are not compatible with Eclipse 3.2 runtime. Also older Eclipse projects have came with lots of new features and enhancements. Most of these new features does not work in Eclipse 3.2. Also most of the new projects are not making their projects compatible with Eclipse 3.2. This has been biggest handicap for us. We were unable to include newer plug-ins or projects in our product. Migration to Eclipse Galileo enabled us to use newer Eclipse projects and frameworks.
d) Unavailability of Task management:
For providing task management, new project , called Mylyn, has started under Eclipse projects. It's open source implementation of the Task-Focused Interface. It provides an Application programming interface (API) for tools embedding the task-focused interface. Generally developer works on lots of modules simultaneously. Most of the tasks are need to be revisited. For example, in my project I have written code for writing file in simple text format. After one month my manager asked me to write all the files in XML format. To add this functionality, I have to modified code which write file in text format. Also I may need to modify all the references which are getting affected by change. In my projects there are lots of source files and thats why my most of the time will went in finding out right code to be modified. Mylyn would be helpful in such situation. Using Mylyn, I can create task (such as Text file writing operation) before working on that task. This task gets stored in my workspace. Mylyn records all the files or code fragment which are used while working on code. So whenever I want to modify any particular task, I can simply activate that task. After activating task, Mylyn will show only those code fragments which are added or modified while working on task. So you don't have to iterate over all the code to search right code. This is very good feature if you are working on large code base. You can integrate bug management system like Bugzilla, Trac, Redmine, JIRA, etc in Mylyn. This helps to integrate your bugs and code in one development environment. Also Mylyn allows you to share your tasks with other developers. So Mylyn focuses on improving productivity by reducing searching, scrolling, and navigation. By making task context explicit, Mylyn is also meant to facilitate multitasking, planning, reusing past efforts, and sharing expertise.
In our product, user has to manage lot of files and projects. So use of Mylyn could be beneficial for user. But lots of Mylyn features are not available in Eclipse 3.2. That's why task management becomes one of the reason for migration of our product to Eclipse 3.5.
e) Extended platform support :
As we already know, Eclipse is a platform independent framework. Although it is said to be platform independent, it doesn't support all the platforms. Eclipse 3.2 was supporting very less number of platforms. Also on some platform, Eclipse 3.2 was not providing all the functionality. There is a drastic improvement on this front in newer Eclipse. Now Eclipse has started supporting all the newer Windows OS, most of flavors of Linux, Mac, Solaris x86, S390, S390x, HP-UX. Now it also started supporting most of 32 bit and 64 bit platforms. Now due to newer implementation of OSGi specification using Equinox project, Eclipse has started running on most of mobile OS and embedded devices. This helps Eclipse to become more portable and platform independent in true means. It also helps in increasing acceptability of Eclipse.
Currently our product only runs on Windows OS. To increase the portability and acceptability of our product, we have to deploy our product on newer Eclipse runtime.
f) Generics support :
In our product, we have embedded lot of Eclipse based projects such as Eclipse Modeling Framework (EMF), Graphical Editing Framework (GEF), Graphical Modeling Framework (GMF), etc. Eclipse Modeling Framework (EMF) is an Eclipse-based modeling framework and code generation facility for building tools and other applications based on a structured data model. Our product uses EMF 2.2. But this EMF does not supports Generics. Newer version of EMF supports generics and it generates model code, which consist of Generics. But newer EMF version (EMF 3.5) doesn't maintain backward compatibility with Eclipse 3.2 runtime.
In our product, we have to use Generics feature to upgrade some of our existing tools. But for Generics support, we have to upgrade to EMF 3.5 and ultimately upgrade to Eclipse 3.5 runtime.
g) Zest :
Eclipse has started really promising project under Graphical Editing Framework (GEF) called Zest. Zest - Eclipse Visualization Toolkit, is a set of visualization components built for Eclipse. The primary goal of Zest is to make graph based programming easy. In our product, we have lot of graph like structures and we wanted to present these using better user interfaces. To fulfill this requirement, we can use Zest project. But as Zest doesn't support Eclipse 3.2, we have to migrate our product to Eclipse 3.5.
h) Better memory management :
Eclipse is based on plug-n-play architecture. That means only those components, in Eclipse's word Plug-ins, are loaded which are required. This makes Eclipse, memory efficient. But still Eclipse is having lots of memory related issues. Once plug-ins are loaded, they can not be unloaded at runtime. Eclipse manages all the system resources through Eclipse File System (EFS). So resource accessed through some Eclipse API need to managed properly and must be unallocated after use. In older Eclipse API, resources accessed through EFS was not memory efficient. But lot of improvement has been made to handle these memory leaks. Newer versions of Eclipse manages memory in far better way. Improvement in Eclipse API drives Eclipse based projects to work on memory management. For example, in EMF 2.2 one EObject was taking 120 bytes of memory but in EMF 2.5 one EObject is only taking 12 Bytes.

Eclipse Tips and Tricks

2009-09-23T22:56:00.000-07:00

1) Path for tool bar and menu bar can be found in org.eclipse.ui.IWorkbenchActionConstant
2) Code to find out an active shell
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getShell()
3) To find out an active page
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()
4) To access file from workspace
ResourcesPlugin.getWorkspace().getRoot().getFile(IPath)
5) To access projects from workspace
ResourcesPlugin.getWorkspace().getRoot().getProjects()
6) To create an uri from file location
uri = org.eclipse.core.runtime.URIUtil.fromString("file://" + "C:/test.txt");
7) To open external file in an eclipse editor
IFileStore fileStore = org.eclipse.core.filesystem.EFS.getStore(uri);
org.eclipse.ui.ide.IDE.openEditorOnFileStore(activePage, fileStore);
8) To open external file in an external editor
IDE.openEditor(page, uri, IEditorRegistry.SYSTEM_EXTERNAL_EDITOR_ID, true );

Inno setup to wrap your Eclipse RCP application

2009-03-16T02:33:00.000-07:00

Last night, I created an Eclipse RCP application. My requirement was to create an installer. By creating installer , you can wrap your rcp application. For creating installer, I used Inno Setup utility. You can download this utility from http://www.innosetup.com.By simply installing Inno Setup, you can create installer script using given editor. Simpler installer script can be look as below:

[Setup]
AppName=SSApp
AppVerName=SSApp version 1.0.0
DefaultDirName={pf}\SSApp
DefaultGroupName=SSApp
[Files]
Source: SSApp.exe; DestDir: {app}
Source: Readme.txt; DestDir: {app}; Flags: isreadme
#include "VFP8Runtimes.txt"
[Icons]
Name: {group}\SSApp; Filename: {app}\SSApp.exe

Using this utility, you can create installer to fulfill following requirements:
· requiring the user to accept to a license agreement before installation;
· specifying a minimum operating system version on the target machine;
· creating registry entries;
· displaying custom graphics in the setup wizard;
· organizing the installation into components; and
· installing database files to a different location than the application itself.

For more information, I can go through following pdf.
www.ita-software.com/papers/FT410_Borup_InnoSetup2.pdf

Persisting information in Eclipse

2009-03-03T22:34:00.000-08:00

When you work on eclipse product, you may need to persist the information related to your product session. One way to persist the information is store it in your workspace. For storing the information in your workspace, you can use Eclipse Preferences. For creating and handling the preferences , you can use “org.eclipse.core.runtime.preferences” extension point. Using this extension point , you can create scope, initialize preference variables, etc. But these preferences are persisted in the runtime workspace. So if you switch the runtime workspace, all these persisted data will not be available. But there might be some scenario in which you can not store these information in runtime workspace. For example, you want to keep track of number of user using your product, or If your product allows user to create diagrams, then to find out how many diagrams are getting created in entire system. Above said example can not store this data in workspace. You can store this data in your product's installed directory. Eclipse provides final class “org.eclipse.core.runtime.preferences.ConfigurationScope” to store the data in installed directory. Following snippet of code shows how you can store your data :

import org.eclipse.ui.preferences.ScopedPreferenceStore;
import org.eclipse.jface.preference.IPreferenceStore;
import org.eclipse.core.runtime.preferences.ConfigurationScope;

public final class StoreManager {
.....
.....
final private static ScopedPreferenceStore store = new ScopedPreferenceStore(new ConfigurationScope(), "com.zensar.sbp.ui.editor");

private void store(){
.........
store.setValue(“Key”, Count);
try {
// persist value to hard disk.
((ScopedPreferenceStore)preferenceStore).save();
} catch (IOException e) {
........
}
.....
}
.....
private int retrive(){
.......
return preferenceStore.getInt(“Key”);
}
.....
}

You can find the persisted information in your products installed directory (in configuration folder).

2009-01-14T00:29:00.000-08:00

While exploring ECF(Eclipse Communication Framework), I found a very interesting and helpful tutorial. This will help you to understand the concepts of ECF.

Cola: Real-Time Shared Editing from Mustafa K. Isik on Vimeo

World of Rule Engine

2008-08-05T02:00:00.000-07:00

In my current project I have started using Drools rule engine. So I just want to describe my experience with this engine. Rule engine, itself, is quite interesting concept.

In plain English we can define Rule Engine as “an engine (can be made using software/ hardware) which validates the facts against certain conditions”. To understand this let’s consider following example:

We have some condition as follows :

1) If it’s cold, stay in home.

2) If it’s night, turn on the lights.

These conditions are known to Rule engine. Now suppose we gave following statement as a input to rule engine:

1) It’s night.

Then Rule engine will return result as “Turn on the lights”.

Suppose we gave input as:

1) Its cold and its night.

Then rule engine will return “Stay in home and turn on the lights”.

So from the given input rule engine extracts facts, validate it with internal facts and generate the output. These can be used to validate complex business rules. From this, concept of BRMS (Business Rule Management System) evolved. A BRMS or Business Rule Management System is a software system used to define, deploy, execute, monitor and maintain the variety and complexity of decision logic that is used by operational systems within an organization or enterprise.

To develop your own BRMS, there is standard JSR 94 available. All existing and popular rule engines are complained with JSR 94. Drools, Jess, JRule are the example of JSR 94 complained rule engines.

About Eclipse's Class Loading by Scott Lewis

2008-05-17T06:22:00.000-07:00

In my last post Comments by Scott Lewis was not visible properly. Here is comment
once again.
------- Comment #3 From Scott Lewis 2005-03-14 11:21:43 -0400 -------

(In reply to comment #1)

We on the ECF team have another case where OSGI classloading creates
a bit of an issue: object serialization.  Jeff McAffer asked me to
attach the following use case to this bug and he and Pascal will
correlate with the other object serialization discussions/reports
for the Equinox effort.

Here's a use case that shows problems with classloading during object
(de)serialization...caused by the way that classes are loaded across
bundles in OSGI, and the way that packages are exported.  Send any
requests for more information about this issue to slewis@composent.com.
We have example code/bundles that show the behavior described below.

The situation:  three plugins/bundles (labelled A, B, C).  Each
plugin is assumed to be duplicated on a remote process
(with plugins labelled A', B', C' on the remote process).
Below is a brief description of the relevant characteristics
of the three plugins.  The plugin names and class names in
parens are ones that actually show this behavior with the
ECF codebase (using EMF to implement a shared EMF editor).

1) Plugin A (org.eclipse.emf.ecore.sdo):  Declares
serializable class (EChangeSummaryImpl) and exposes this
class via the Eclipse plugin "export" declaration like this:

<runtime>
 <library name="runtime/ecore.sdo.jar"/>
 <export name="*"/>
 </library>
</runtime>

This *EMF plugin* (and of course any others like it) does
*not* expose itself through the OSGI manifest.mf, but rather
through the Eclipse plugin mechanisms (only).  Although I'm
not sure, I believe that  is actually implemented as an OSGI
'Provide-Package', and *not* an 'Export-Package'.

2) Plugin B (org.eclipse.ecf.provider):  Creates ObjectOutputStream
(for sending) and ObjectInputStream (for receiving) for a given
container.  Also declares DynamicPackage-Import: *, so that
it's classloader (and the classloader for ObjectInputStream)
will see any packages that have been exported via OSGI
Export-Package.  Using DynamicPackage-Import: * is kind of clumsy and
inefficient (as it means that the ObjectInputStream's classloader
may consider lots of classes that it shouldn't), but it works in OSGI 3.0.

3) Plugin C (org.eclipse.ecf.sdo):  Creates actual instances of
EChangeSummaryImpl and serializes them using an ECF container instance
created/loaded by plugin B.  The sender classloader (C) can see the
EChangeSummaryImpl class because of the Eclipse package export, and the
ObjectOutputStream (created by B's classloader) already has the
classloaded (by C's classloader).

Here's the ACTUAL RUNTIME BEHAVIOR:   C sends via objectoutputstream
created by B an instance of EChangeSummaryImpl (from A) to other
process(es).

on other side of the object stream are three plugins A', B', C'
that are assumed to have the same code as A, B, C.

Plugin B''s ObjectInputStream tries to find the serialized class
EChangeSummaryImpl.  B' has DynamicPackage-Import: *, so it looks
for and will find *any class that has been exposed via Export-Package*.
BUT A' has *not* exposed EChangeSummaryImpl via Export-Package
(only via Provide-Package), and so the classloader fails to find
EChangeSummaryImpl, and the deserialization will
fail also.

In general, this object serialization problem is this:
There could be a lot of
other plugins (ours and others) that are like Plugin A, in that
they provide serializable classes, are *not* produced/built by
the ECF that creates the objectinput/output stream, but which
are createable, etc by ECF plugins B (and C, D, etc)
because of the (static) plugin dependencies, but are *not* available
to ObjectInputStream's classloader because they haven't declared
Export-Package in their manifest.mf, and the OSGI classloader
(EclipseClassLoader) only looks for/finds packages (at runtime)
that are exposed via
Export-Package....Sooo...the classloader for the ObjectInputStream fails to
find/load these classes, and the deserialization fails.

ClassLoading in Eclipse and it's effect.

2008-05-17T05:39:00.000-07:00

Every one knows that each eclipse plug-in has it's own class loader. This class loader loads plug-in on request of Eclipse Runtime. Due to this architecture i faced some issues while working on ECF(Eclipse Communication Framework). I was developing on application which uses ECF to share the editors. To share information i used to send one serializable message i.e SharedObjectMsg across two Eclipse Runtime Instances. ECF internally serializes passed message and passes it across the network. But at the receiving end i was unable to receive that message. I tried out all the stuff and check out all my code but could not solve the problem. Then i come across Bug 87775 on eclipse Bugzilla. From there i got the solution to solve this problem.I exposed all messages in menifest.mf of my plug-in which defines messages. As i did not exposed these messages earlier, ECF's org.eclipse.ecf.provider could not saw my messages. "org.eclipse.ecf.provider" does all the serialization and de-serialization job. But as it could not see my messages serialization failed. But eclipse or ECF does not notify us about this failure. There was no exception thrown. For details , go through the comment's by Scott Lewis given in Bug 87775.::

------- Comment #3 From Scott Lewis 2005-03-14 11:21:43 -0400 -------

(In reply to comment #1)

We on the ECF team have another case where OSGI classloading creates a bit of an
issue: object serialization.  Jeff McAffer asked me to attach the following use
case to this bug and he and Pascal will correlate with the other object
serialization discussions/reports for the Equinox effort. 

Here's a use case that shows problems with classloading during object
(de)serialization...caused by the way that classes are loaded across bundles in
OSGI, and the way that packages are exported.  Send any requests for more
information about this issue to slewis@composent.com.  We have example
code/bundles that show the behavior described below.

The situation:  three plugins/bundles (labelled A, B, C).  Each plugin is
assumed to be duplicated on a remote process (with plugins labelled A', B', C'
on the remote process).   Below is a brief description of the relevant
characteristics of the three plugins.  The plugin names and class names in
parens are ones that actually show this behavior with the ECF codebase (using
EMF to implement a shared EMF editor).

1) Plugin A (org.eclipse.emf.ecore.sdo):  Declares serializable class
(EChangeSummaryImpl) and exposes this class via the Eclipse plugin "export"
declaration like this:


 
   
 


This *EMF plugin* (and of course any others like it) does *not* expose itself
through the OSGI manifest.mf, but rather through the Eclipse plugin mechanisms
(only).  Although I'm not sure, I believe that  is actually
implemented as an OSGI 'Provide-Package', and *not* an 'Export-Package'.

2) Plugin B (org.eclipse.ecf.provider):  Creates ObjectOutputStream (for
sending) and ObjectInputStream (for receiving) for a given container.  Also
declares DynamicPackage-Import: *, so that it's classloader (and the classloader
for ObjectInputStream) will see any packages that have been exported via OSGI
Export-Package.  Using DynamicPackage-Import: * is kind of clumsy and
inefficient (as it means that the ObjectInputStream's classloader may consider
lots of classes that it shouldn't), but it works in OSGI 3.0.

3) Plugin C (org.eclipse.ecf.sdo):  Creates actual instances of
EChangeSummaryImpl and serializes them using an ECF container instance
created/loaded by plugin B.  The sender classloader (C) can see the
EChangeSummaryImpl class because of the Eclipse package export, and the
ObjectOutputStream (created by B's classloader) already has the classloaded (by
C's classloader).

Here's the ACTUAL RUNTIME BEHAVIOR:   C sends via objectoutputstream created by
B an instance of EChangeSummaryImpl (from A) to other process(es).

on other side of the object stream are three plugins A', B', C' that are assumed
to have the same code as A, B, C.

Plugin B''s ObjectInputStream tries to find the serialized class
EChangeSummaryImpl.  B' has DynamicPackage-Import: *, so it looks for and will
find *any class that has been exposed via Export-Package*.  BUT A' has *not*
exposed EChangeSummaryImpl via Export-Package (only via Provide-Package), and so
the classloader fails to find EChangeSummaryImpl, and the deserialization will
fail also.

In general, this object serialization problem is this:   There could be a lot of
other plugins (ours and others) that are like Plugin A, in that they provide
serializable classes, are *not* produced/built by the ECF that creates the
objectinput/output stream, but which are createable, etc by ECF plugins B (and
C, D, etc) because of the (static) plugin dependencies, but are *not* available
to ObjectInputStream's classloader because they haven't declared Export-Package
in their manifest.mf, and the OSGI classloader (EclipseClassLoader) only looks
for/finds packages (at runtime) that are exposed via
Export-Package....Sooo...the classloader for the ObjectInputStream fails to
find/load these classes, and the deserialization fails.

Jax India 08 conference

2008-05-13T22:04:00.000-07:00

I am writing this blog after so many days. Last month I have been to Jax India 08 conference. Neeraj and Saurabh also attended conference with me. We are three people from Zensar Technologies. There were three forums and you can attend seminars in any forum. We mainly gave stress upon Eclipse forum. For eclipse forum there were two speakers, one is Chris Aniszczyk and Wayne Beaton. Both were good speakers and they explained about Eclipse and project in Eclipse. Good part is we could interact with them personally. There were one keynotes presented by Roy Singham - Founder Chairman – ThoughtWorks. He was pretty impressive in delivering his point. He provides good insight of software domain. I will try to put some photos of Jax India Conference in my next blog .

Fluent Interfaces.

2007-10-24T21:30:00.000-07:00

Yesterday in teams discussion Ravi tossed up the term Fluent Interface. Fluent interface is term originally tossed up Martin Fowler and Eric. These type of interfaces are used for creating DSL. API are designed in such a way that object sequence describe flow of sequences. According to definition , a fluent interface is an objected oriented construct that defines a behavior capable of relaying the instruction context of a subsequent call
One criticism about Fluent interface is that it is not so readable. Another thought is that individual method of an class does not mean anything. If we apply method collectively then only it make sense.
Basically using Fluent Interfaces, API s are designed in such a way that it looks like new language. That's why these interface are mainly used in Internal DSL(Domain Specific Languages).

GEF's flow

2007-08-01T21:04:00.000-07:00

When you start learning GEF, some basic question comes to your mind such as “What is the flow of GEF?” or “What happens when I select any component of palette and draw it on canvas?”. In this post I will try to describe what all the things GEF does before drawing your figure on canvas.

1) User clicks on some elements of palette.

2) A Creation tool gets activated.

3) As soon as you click on the viewer creation tools calls performCreation method.

4) performCreation method find out current EditPartViewer. EditPartViewer is nothing but org.eclipse.jface.viewer.IselectionProvider. This manages editpart’s lifecycle. This is an interface and user should not implement this. User must extend abstractEditPartViewer.

5) After this targeting tool comes into the picture. Targeting tool returns the creation command.

6) Command gets executes and new model gets added to the parent model.

7) Notification send to each listeners, i.e. parent edit part and property sheet, etc.

8) Parent editpart calls method refreshChildren().

9) AbstractEditPart then creates new edit part for object being dropped using editpart factory.

10) AbstractEditPart then calls addChildVisual() method for adding visuals for the dropped object. Required figure is obtained from createFigure() method of particular editpart.

11) addNotify() gets called on the child editpart. This will ask editpart to refresh itself for first time.

12) Child editpart then calls active() method for installing all the edit policies associated with it.

13) Creation tools then selects current dropped object.

This is how objects gets created when you drag it from the palette. Following figure shows summery of the above steps.

I just provided abstract flow of ‘creation of object’. Internally GEF does some more things before this creation. You go on and explore the same.

GEF's Model Adaptability

2007-07-24T21:27:00.000-07:00

GEF provide very nice way to adapt your model. Basic aim of creating GEF was :-
"Create Graphical editor for your domain model".
This means we are not going to change our domain model, but still it should provide business data to our editor. Once you adapt your model to GEF , then GEF will provide lot of help for displaying it graphically. Basic requirement of GEF for your model is :
Model should provide notification mechanism.

You can adapt EMF, XML, PojO model with the GEF. As EMF(Eclipse Modeling Framework ) provides very flexible model , it can be easily adapted with GEF.

2007-07-23T21:16:00.000-07:00

JUnit Testing of GEF(Graphical Editing Framework) application

Introduction

Extreme Programming is software engineering methodology which is the prominent member
of agile technique.JUnit is one of the framework using which one can execute XP in real life.
Graphical Editing Framework provides a rich, consistent graphical editing environment.

This article will use Shape Diagram example to illustrate the writing of JUnit test cases.
This article will also briefly demonstrate how to write JUnit Plug-in tests.

Need

Path for learning GEF framework is quite long. You need to understand different design patterns before
learning GEF because GEF uses design patterns extensivly.Suppose, Let's consider following two scenario.

a) If you are expert in GEF and you have developed one GEF application. Now you have to explain this application
to one who understands GEF. It is really time consuming task to explain him each and every thing of your
application. But if you have written test cases for your GEF application then you can ask him/her to go through
test cases. He will defiantly understand application much faster than conventional method.

b) Normally GEF application has large code base. So it is difficult to maintain consistency between different
parts of application. Suppose you changed something in one part then it may affect other parts of your application.
To keep a track to this you need to test your application regularly. It's time consuming and repetitive process.
But if you have test cases written for different units of your application, you can easily run all unit test cases
and check the consistency.

You can find many such scenario which describes importance of unit testing. Now let's write test cases for well known
GEF's Shape example.

For more details about this example please refer to
article by Bo Majewski,"A Shape Diagram Editor".

Before writing any test cases i would like to tell some good practices for writing test case.

a) Try to avoid writing test case inside your source folder.
In our case we created a TestCases folder on the same level as of source folder (Fig 1).

Fig. 1

b) Always give fully qualified name for test method.

 
public void testConnetionWithSameSourceAndDestination() throws Exception {
  ShapesDiagram shapeDiagram = createProject();
  try {
   Connection connection = new Connection(ellipcticalShape,ellipcticalShape);
  } catch (IllegalArgumentException e) {
   System.err.println("Can not make connection between same source and destination");
  }
 }

In the preceding example,

method will check connection with same source and destination.

There are lots of best practices available for Unit testing. For more detail about Best Practices, refer to article by Andy Schneider,"
JUnit best practices".

Writing JUnit test cases

1) Import Shape Example : Download and unzip the latest GEF Examples's source code from the GEF Project Downloads. Using this source create plug-in project

2) Create package for test cases : Create a package 'TestCases' on same level as that of Source folder(Fig 1).

3) Create Test Cases : By right clicking TestCases package select New->JUnit Test Case.Make sure that you extend super class junit.framework.TestCase.A test case defines the fixture to run multiple tests. Click on checkbox to override setUp() method. Setup method will initialize the environment for your test cases. For doing clean up after tests, you can override tearDown method.

You can also provide "Class Under Test" in browse option. For example, we select ShapesEditor as "Class Under Test".After Clicking next button you will get all the method of ShapeEditor class.If you select one of the method, test case for that method will get created. Suppose we selected doSaveAs() method.

JUnit will create test method for you named testDoSaveAs().

 /**
  * Test method for {@link org.eclipse.gef.examples.shapes.ShapesEditor#doSaveAs()}.
  */
 public void testDoSaveAs() {
  fail("Not yet implemented");
 }

This test method will be automatically discovered by test annotation.

4) Setup the case :

In setUp method (1) you need to initialize the environment. Means in our case we need to create a new project. Following method createProject(3) shows how to create new project. Method setShapeDiagram(shapeDiagram)(2) is used for encapsulating shapeDiagram object.

 /*
  * This method sets up the environment
  *
  * @see junit.framework.TestCase#setUp()
  */
 @Override
 (1)Protected void setUp() throws Exception {
  super.setUp();
  shapeDiagram = createProject();
  (2)SetShapeDiagram(shapeDiagram);
 }

 private ShapesDiagram createProject() throws Exception {
  IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
  IProject project = root.getProject(projectName);
  if (!project.exists())
   project.create(null);
  if (!project.isOpen())
   project.open(null);
  file = project.getFile(fileName);
  ShapesDiagram shapeDiagram = null;
  if (!file.exists()) {
   shapeDiagram = createShapesDiagram();
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   ObjectOutputStream oos = new ObjectOutputStream(out);
   oos.writeObject(shapeDiagram);
   oos.close();
   file.create(new ByteArrayInputStream(out.toByteArray()), false,
     null);
   out.close();
  } else {
   ObjectInputStream ooin = new ObjectInputStream(file.getContents());
   shapeDiagram = (ShapesDiagram) ooin.readObject();
  }
  return shapeDiagram;
 }

 /**
  * @param shapeDiagram the shapeDiagram to set
  */
 void setShapeDiagram(ShapesDiagram shapeDiagram) {
  this.shapeDiagram = shapeDiagram;
 }

createShapesDiagram() (/*4*/) creates models to be represented in Viewer. Let's look how you can write this method.

 private ShapesDiagram createShapesDiagram() {
  (1)ShapesDiagram shapeDiagram = new ShapesDiagram();
  (2)ellipcticalShape = new EllipticalShape();
      ellipcticalShape.setLocation(new Point(50, 50));
  (3)rectangularShape = new RectangularShape();
      rectangularShape.setLocation(new Point(150, 150));

      shapeDiagram.addChild(ellipcticalShape);
      shapeDiagram.addChild(rectangularShape);

      return shapeDiagram;
 }

In above code, we first create model object Shape diagram (1). We add two shapes (elliptical (2)and rectangular (3)) to diagram model. You can set any co-ordinates to these shapes.

5) Writing test case : Now we will right our simple test case for checking the connection. testConnection() method makes connection between ellipse and rectangle. Another method testConnetionWithSameSourceAndDestination() creates connection between two same model i.e ellipticalShape. Look carefully, here we catch exception thrown by the code. For creating the connection we just need to create 'Connection' object and pass two model to it as an arguments.

 public void testConnection() throws Exception {
  ShapesDiagram shapeDiagram = getShapeDiagram();
  Connection connection = new Connection(ellipcticalShape,rectangularShape);
  writeToFile(shapeDiagram); /* [1] */

 }

 public void testConnetionWithSameSourceAndDestination() throws Exception {
  ShapesDiagram shapeDiagram = getShapeDiagram();
  try {
   Connection connection = new Connection(ellipcticalShape,
     ellipcticalShape);
  } catch (IllegalArgumentException e) {
   fail("Can not make connection between same source and destination");
  }
  writeToFile(shapeDiagram);
 }

 private void writeToFile(ShapesDiagram shapeDiagram) throws IOException, CoreException {
   ByteArrayOutputStream out = new ByteArrayOutputStream();
   ObjectOutputStream oos = new ObjectOutputStream(out);
   oos.writeObject(shapeDiagram);
   oos.close();
   IWorkspaceRoot root = ResourcesPlugin.getWorkspace().getRoot();
   IProject project = root.getProject(projectName);
   file = project.getFile(fileName);
              file.setContents(new ByteArrayInputStream(out.toByteArray()), false, false, null);
   out.close();
  }

 /**
  * @return the shapeDiagram
  */
 ShapesDiagram getShapeDiagram() {
  return shapeDiagram;
 }

writeToFile method will write models to the file. This method uses simple ByteArrayOutputStream to serailize model.

Now in next section we will see how to run the test cases.

6) Running test cases : Right click on the project and select Run As -> JUnit Plug-in Test.

After completion of JUnit Plug-in test, "JUnit" view opens up with description of tests. It shows information about total test runs, number of test failed, errors and failure trace(Fig 5).

Fig 5

In above Fig 5, you can see that 'testConnection' test succeeded. It is marked with right arrow. Another test 'testConnectionWithSourceAndDestination' failed and it is marked using cross. In adjeccent window you can see failure trace. This failure trace shows reason of failure. It shows message which we gave in test method.

BarCamp3 Pune

2007-07-16T21:21:00.000-07:00

Last weekend i attended bar Camp. I attended barcamp first time. It was nice experience. I and Neeraj gave presentation on Graphical Editing Framework. It was my first talk in such events.It was very nice experience. It's nice when people ask some questions and you try to fulfill there queries. This will help you to make perfect.
Looking forward for such events.

ThoughtWork's The Master Class Series

2007-05-27T21:23:00.000-07:00

On this Sunday i attended 'Master Class Series' organized by ThoughtWork. It was a nice talk.

First talk was about Refactoring of the database. It was presented by Pramod Sadalage. Mainly he talked about refactoring, rearranging databases. He also explained some patterns of database refactoring. He mainly explain that you should consider your database as a part of your source code.They found out some patterns while working with databases. I really like concept of making local copy of database. Main advantage of this, is you can do experimentation with your local copy.
Even if one developer make mistake it would not affect team.

Second talk was "Evolutionary Testing" by Vivek Prahlad. In this he talked about automating your testing. He also showed some tools for automate your tests. He also explains basic principle for writing test cases and test suites.

Lat talk was about Domain Specific Languages. These are the languages designed for a specific kind of tasks. Example of such languages are macros of Word, shell scripts, YACC(Yet Another Compiler Complier) .Thoughtwork developed such language for their project. He mainly specify the use and context where we can use DSL.

Overall these talks are very informative.

Writing article for JUnit testing of GEF application.

2007-05-23T21:17:00.001-07:00

This has been very busy month for me and my team mates at Zensar. We are going through final phase of development and refactoring before release of product. We are planning to release it at the end of the month. That's why this scrap comes after long days. I have also writing an article for "JUnit test of GEF application". It's really hard to find time for this when you are in the final phase of your product delivery. I am trying my best for completing my article as early as possible.So let's hope for the best.