Migration of Eclipse based products :- Need of time

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

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

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

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).

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

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

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.