Hi Hristo,
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.
Scott
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.
Regards,
Hristo Iliev
On 16 February 2011 23:00, Scott Lewis <slewis@xxxxxxxxxxxxx>
wrote:
Question about use case 2:
2. Provision Virgo via p2 - the user uses p2 to provision
and start Virgo.
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?
Thanks,
Scott
On 2/16/2011 2:03 AM, Glyn Normington wrote:
Hi Katya
On 16 Feb 2011, at 09:41, Todorova, Katya wrote:
Hi Glyn,
The difference among the Virgo deliverables is only
the list of initial artifacts specified in
userregion.properties?
Yes that's the main difference, and the existence of
those artifacts in the repository of course. There may
be other small config differences.
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
inside it.
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
startup to).
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
use cases,
he will just have two options for "downloading" Virgo
to his local machine.
Perfect!
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.
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?
Yes. Thanks for the clarification.
Regards,
Glyn
Thanks,
Katya
-----Original Message-----
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
Hi Pascal
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
admin
console, and hosted repository server.
Virgo kernel includes just the container and no
apps.
Virgo Jetty server includes the container and some
pre-installed apps.
Where does the use case of "the user downloads
virgo,
starts it and install an application using p2" fit?
That's a good use case, but not one that I need to
draw to
people's attention as it is already high on the list
from a
Virgo& p2 perspective.
How much flexibility is there in terms of changing
the
layout of the actual runtime to maybe make it more
"manageable" from a p2 standpoint and still
accommodate the
two scenarios?
Quite a lot, some of which has been tried already.
We simply
need to ensure that the user's tasks in these use
cases is
not made more difficult. In particular we need to
ensure that
configuration is not duplicated and that
configuration is
documented as well, and edited as easily, as today's
property files.
Regards,
Glyn
On 2011-02-15, at 10:33 AM, Glyn Normington wrote:
Following last week's discussion of p2, I would
like to
ensure that the following use cases work when we
eventually
integrate Virgo and p2:
1. Unzip and go - the user downloads and unzips
Virgo,
edits config files, and runs a startup script, much
like in
2.1.0. No need to invoke p2, although it is
acceptable for p2
to run under the covers.
2. Provision Virgo via p2 - the user uses p2 to
provision
and start Virgo.
3. "Hybrid" - the user uses p2 to provision
Virgo, edits
config files, and runs a startup script, the latter
two steps
much like in 2.1.0.
Regards,
Glyn
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
|