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.

ClassLoading in Eclipse and it's effect.

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

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 .