Ok, thanks for the clarification. I just wasn't clear on whether
use case 2 covered the in-place provisioning...but it sounds like it
does. FWIW, I'm very happy to hear that.
On 2/16/2011 1:48 PM, Hristo Iliev wrote:
We aim to do that possible as well. The steps to
enable the in place provisioning:
1) equinox launcher
2) all Virgo bundles in one directory (plugins)
3) p2 to provision Virgo
4) runtime/deploy integration with P2
I'm quite sure I'm missing something but basically that's what we
have to do. We have some progress on 1 and 2 and now we are facing
the third step.
On 16 February 2011 23:00, Scott Lewis <slewis@xxxxxxxxxxxxx>
Question about use case 2:
Will it be possible to install Virgo into an existing
Equinox+p2 framework (i.e. 'in place')? That is, starting
from Equinox+p2 only, will it be possible to install the Virgo
bundles into that framework, and then after starting the
appropriate Virgo bundles/services...have other bundles be
able to use Virgo/Spring APIs?
2. Provision Virgo via p2 - the user uses p2 to provision
and start Virgo.
On 2/16/2011 2:03 AM, Glyn Normington wrote:
On 16 Feb 2011, at 09:41, Todorova, Katya wrote:
Yes that's the main difference, and the existence of
those artifacts in the repository of course. There may
be other small config differences.
The difference among the Virgo deliverables is only
the list of initial artifacts specified in
Currently which are the config files which are
expected to be modified by hand after the uzip?
All of them. ;-) That is the kernel properties file in
lib and the files in config.
The second use case should be just initial
provisioning of Virgo. Here we still don't have p2
I mean the zip content and the result of p2
installation should be the same so there is nothing
specific/new in starting Virgo (no p2 to delegate the
Here you can consider initial p2 installation as an
alternative to uzip. For the end user there won't be a
difference in terms of functionality between these two
he will just have two options for "downloading" Virgo
to his local machine.
The third use case is having p2 inside Virgo - as soon
as the server is started p2 is used to install the
additions or updates if there are such.
Yes. Thanks for the clarification.
Here p2 should update the Virgo config files. The
questions above are related to this use case. So are
Pascal's questions I guess.
My point is that the initial provisioning is not
coupled with the Virgo architecture (whether it uses
p2 or not for example).
The end user can decide independently:
- how to get Virgo (uzip or installed by p2) and
- what kind of distribution to have (with or without
p2 support, kernel/jetty/web, etc)
Does this make sense?
From: Glyn Normington [mailto:gnormington@xxxxxxxxxx]
Sent: Wednesday, February 16, 2011 10:49 AM
To: Pascal Rapicault
Cc: Virgo Project; Todorova, Katya; Stanev, Georgi
Subject: Re: Virgo& p2 use cases
On 16 Feb 2011, at 04:23, Pascal Rapicault wrote:
In this description, what is "Virgo"? The
container and the
application, or just the container?
For these use cases there are currently three Virgo
deliverables that we should take into account:
Virgo web server includes the container and some
pre-installed applications: the splash screen, web
console, and hosted repository server.
Virgo kernel includes just the container and no
Virgo Jetty server includes the container and some
Where does the use case of "the user downloads
starts it and install an application using p2" fit?
That's a good use case, but not one that I need to
people's attention as it is already high on the list
Virgo& p2 perspective.
How much flexibility is there in terms of changing
layout of the actual runtime to maybe make it more
"manageable" from a p2 standpoint and still
Quite a lot, some of which has been tried already.
need to ensure that the user's tasks in these use
not made more difficult. In particular we need to
configuration is not duplicated and that
documented as well, and edited as easily, as today's
On 2011-02-15, at 10:33 AM, Glyn Normington wrote:
ensure that the following use cases work when we
Following last week's discussion of p2, I would
integrate Virgo and p2:
edits config files, and runs a startup script, much
1. Unzip and go - the user downloads and unzips
2.1.0. No need to invoke p2, although it is
acceptable for p2
to run under the covers.
and start Virgo.
2. Provision Virgo via p2 - the user uses p2 to
config files, and runs a startup script, the latter
3. "Hybrid" - the user uses p2 to provision
much like in 2.1.0.
virgo-dev mailing list
virgo-dev mailing list