Forum Controls
Spotlight Features

The Rich Engineering Heritage Behind Dependency Injection

Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.

Java, the OLPC, and community responsibility

The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!
Replies: 0 - Pages: 1  
  Click to reply to this thread Reply

My journey from a plug-in based to a feature based product configuration.

At 5:42 AM on Feb 5, 2008, Jan Kohnert wrote:

For enable software updates for my RCP application I was faced with the
requirement to change my product configuration from a plug-in based to a
feature based one.
Because it took me about a day just to solve the three major obstacles,
and because in conclusion I believe the difficulties I faced could be
avoidable, I decided to write this post. My intension is to give an
overview of the problems I faced. While searching in newsgroup archive I
found that a substantial amount of people where facing similar or
identical troubles.
All workarounds I found are taken from Newsgroup archive.
Before getting technical I have to say, that as a conclusion of my
‘journey’ I believe that most of the problems could be avoidable! In one
case it seems to be a simple Bug. One case could need Eclipse based
software assistance (wizard?), and the third is just an effect of the bug
that needs a workaround.

So let me start at the beginning:

Part one ‘No application id has been found:
The error ‘no application id found’ occurred the first time I switched
over to a feature based product. It took my some time to get behind the
sheets and to understand what the problem was. When exporting the product
after the change, I noticed, that only a minority of the plug-ins included
in the ‘plug-in based’ build was included into the ‘feature based’ build.
When changing the product configuration from a plug-in to a feature one,
and than switching to the ‘Configuration’ tab, one remarkable change is
the absence of all the plug-ins that where listed there before. Instead
there is a list of the features the product is based on.
The former list of plug-ins was (in my case, and I believe is quite often)
a result of using the handy function ‘Add Required Plug-ins’ inside the
product configurations ‘Configuration’ tab. The list includes all plug-ins
the product is based on and plug-ins that are dependencies of this
plug-ins.
When creating a Feature by adding plug-ins manually within the Feature
Manifest Editor’s Plug-ins tab, only this manually included plug-ins get
selected as feature content. Off cause, there is a ‘Compute’ Button on the
Dependencies tab of the editor, but as it says, all the button does is to
compute a list of dependencies that have to be present when running the
feature.
So what happens when changing the product base to features is, that some
of the plug-ins that constitutes a RCP application does not get exported
anymore. That is simply because a handy mechanism like ‘Add required
Plug-ins’ does not exist once a product configuration is changed to
features. Nobody except the RCP developer have to take care of which
plug-ins get exported once using a feature based product.
To take care of proper plug-in exporting a further feature has to be
implemented including all the plug-ins computed previously from the ‘Add
required Plug-ins’ button. Off cause this button is not visible anymore.
But with changing the product base back to plug-ins, it is visible again
and even the plug-in list shows the correct entries. Each of the plug-ins
on the list has to be inserted manually into the newly created feature
which acts as a runtime plug-in library.
This feature is called ‘library feature’ in the following, where as the
feature containing the custom application plug-ins (the ones I programmed
for my application) is simply called ‘main feature’.
In the Feature Manifest Editor’s tab ‘Included Features’ of the main
Feature this newly created library feature has to be inserted. When
starting or exporting the RCP application, all plug-ins included in the
main feature and the library feature gets exported and as result the
application should run.
But in fact it does not.

Part two ‘Launcher was unable to locate its companion shared library
As soon as I started the application a message dialog appeared telling me
that the launcher was unable to locate its companion shared library. Again
it took some time to find the answer inside of this archive. I’d forgotten
to include a further feature into the Included Features list. The feature
‘org.eclipse.rcp’ has to be included there. It contains a bundle of
plug-ins including core functionality of a common RCP application. Such
as, important plug-ins required for the RCP framework to start. Somehow it
seems that it contains plug-ins that aren’t on the plug-ins list that is
created when adding required plug-ins to a plug-in based product using the
button of the same name.
So after including it into the Included Features list inside the Feature
Manifest editor of my main feature, synchronizing the product and
exporting it, the application started this time.

Part three ‘Invalid signature file digest for Manifest main attributes’
At that point I was sure that the rest of the way to an updatable
application was short. An update site project was created quite fast
(thanks to the help of the various eclipse books) and a tomcat server
running it. After implementing actions to start the UpdateManagerUI I
exported the product once again. I incremented the main Features version
and created it via the update site’s Build button. After copying it onto
the Tomcats’s update site I started the update function out of my RCP
application. Unfortunately as soon I selected a feature to update an error
message was shown in the update dialog’s title area saying: ‘Invalid
signature file digest for Manifest main attributes’.
Searching and reading a lot of this topic inside this newsgroups archive
let me to the conclusion that the ‘org.eclipse.rcp’ feature I had just
includes into my product was responsible for this behaviour because of a
known bug.
The crack for this problem is to create or extend a feature by adding all
plug-ins from ‘org.eclipse.rcp’ into it.
In part one I’d created a library feature that contains the plug-ins
required to run the product. In part two I’d to learn that there are some
plug-ins left that do not seem to be inside my library feature. At this
point it was obvious that I had to figure out what plug-ins had to be
added into the library feature in order to get the application starting
without using the RCP feature. Checking the plug-ins inside the RCP
feature I found four that had administrable names.
• org.eclipse.equinox.common
• org.eclipse.equinox.launcher (+ a os fragment)
• org.eclipse.equinox.preferences
• org.eclipse.equinox.registry

Fortunately adding just this equinox plug-ins did the job. After removing
the RCP Feature from the Included Features section at the Feature Manifest
Editor’s Features tab and adding the above listed plug-ins in the plug-ins
section the product was about to work.
I Synchronized and exported the product once more and repeated the steps
that are necessary to receive an updateable feature on the tomcat’s update
site.
This time it worked. I could start the application and perform an update
to a higher version.

Part four: Conclusion
As a result of the steps done described above, I have two insights
regarding this issue.
First, when you know what have to be done to get a feature based product
run and updatable, it is quite easy and fast to do.
Second, when you do not know what to do, you are left back in the rain.
Unlike common Eclipse RCP development there is now wizard or smart editor
doing the job for you. Handy functions like adding required plug-ins do
not exist, and help can only be found searching for hours. For me it seems
like feature based product configuration is neglected a bit in opposite to
plug-in based.
Product updates using the standard eclipse update mechanism is an
important feature of the Eclipse framework. Using a feature based
configuration for a product is the only way to get updates run. It is
quite sad in my eyes that required development steps needed to get an
updatable product run are not supported ideally. I’m talking about the
struggle getting all required plug-ins for running a feature based product
together. Wouldn’t it be simple to have a button for adding required
plug-ins in the feature manifest editor just like in the product editor?
May be yes, but maybe spamming a feature with plug-ins just to get it run
is also not a reasonable solution. On the other side there is the
dependencies section in the feature manifest editor. Would a checkbox to
include dependencies when necessary at this point would make any scene?
Maybe also not, because plug-ins required by the RCP framework it self
would be missing. Maybe a function to create a runtime library feature
just like the one I created manually in part one of this text would solve
some of the problems. Such runtime library feature off cause needs an
update functions to update the plug-ins included once the dependencies of
the created RCP application change.
This newsgroup archive is full with questions regarding one or more of the
topics I’ve talked about here. My intension writing this text was to point
the problems out I faced and hopefully to help people struggling with just
the same issues. Beyond my intension (but not my hope :) ) in fact is to
inspire people to consider about how things could be simplified.

Thank you for listening :)
Jan Kohnert



thread.rss_message