[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Virgo & p2 use cases

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