[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [virgo-dev] Rationale for the Virgo launcher
- From: Hristo Iliev <hsiliev@xxxxxxxxx>
- Date: Thu, 30 Dec 2010 23:22:26 +0200
- Delivered-to: email@example.com
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=Uz8WUTzgSZMxJz7xpxHjybrkMqNMGvyAqSGWiakLdB7Pn5ldZsFgFc/cns4g1IIDHA YIk91ihJRzVw/5hgpywCQIOkgfOOXyXTPMsETO2UpyoA4D6j/7GNIgIUAzRLH18B4yPe B1ioGuXGwsJv9qfnGPkegA3zSHENITiajDPZQ=
We are indeed working on a prototype that replaces Virgo's launcher with the one from Equinox. The idea for having such prototype is to allow P2 to install Virgo, and
to allow easy setup of target platforms containing Virgo.
This week I was able to create a version that has:
I was not able to run the existing tests, since I had problems with running them on Windows :), but it seems that Virgo is starting ok and the web console is working. What I've done so far was to:
- Equinox launcher
- P2's SimpleConfigurator (lifecycle / bundle list)
- merged lib + lib/kernel + repository into one folder
I think that the first 3 point in the list above correspond almost 1:1 to the launcher's rationale you described:
- change the imports of the Virgo's framework hooks 
- change the dmk shell script (no classpath, replaced -F with -D)
- provide a way to configure the directory structure for the user region (property in the user region configuration + changes in launcher's parser)
- change the kernel.osgi bundle to use the launcher as a bundle
- adapt the build (added parametrized config.ini and bundles.info, new version variables)
T1. The hooks now can be installed as a bundle
T2. Only system properties are used currently (in dmk script) as far as I can tell
T3. The directory structure can be configured
As you can see we are trying to keep the existing functionality and to change as little as possible. Perhaps T3 would not be a big problem, but that remains to be seen.
As additional problems I can point the following:
While the first problem can be solved by simply refactoring the code to allow the use of the launcher as bundle, the second one is not that easy.
- launcher and hooks are used directly (classpath) from the kernel bundles and not by importing the packages
- bundles.info contains bundle list with paths that once populated is hard to be changed (connected with T3)
Btw Borislav is working in parallel on another prototype that will allow flexible startup order and I hope we'll be able to present both (or the merged result) in the middle of January.
If you think that something can be done differently or is already done, please do not hesitate to write back. We'll be happy if you can save us some work :)
 bug 333159
On 30 December 2010 11:56, Glyn Normington <gnormington@xxxxxxxxxx>
At the recent Virgo F2F we discussed the possibility of replacing the Virgo launcher with the standard Equinox launcher.
For the record, the original rationale for creating a Virgo launcher was threefold:
1. to install (just) the required framework hooks
2. to allow command line parameters to be passed in
3. to allow flexibility in the naming of certain directories
Some of these may now be addressed by the Equinox launcher since it has probably moved on, but they should be useful considerations. At the very least, we need to ensure that any replacement launcher passes these tests:
T1. The same set of framework hooks is installed as in Virgo 2.1.0.
T2. All the startup script options in Virgo 2.1.0 are supported.
T3. All the directories can be named as in Virgo 2.1.0.
Clearly these tests may be rendered invalid by new features (e.g. restructuring the directory layout may invalidate T3), but for now they should be useful.
virgo-dev mailing list