Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Provisioning p2 with p2?
Take a look at how the Eclipse SDK is laid out on disk when you have unzipped it. This is the configuration to use if you are writing your own RCP app that will maintain itself. 
In simple terms: the installation directory contains the p2 data area.
A useful exercise is to look at how the p2-installer installs a stand- alone and a shared SDK. 
Look at the properties to see some of the things you can control.
The director.app lets you do this as well, but then you are in full control of all the parameters - so you need 
to know what sort of layout you want and why,
The central thing is the "p2 data area" - the location on disk where p2 keeps its meta data. This data area can be used by any p2 "agent (i.e. running director, engine, etc...), i.e. an external installer, or an "embedded self updater". (If one is currently performing provisioning, it will lock files).
Also note that external provisioning can be done while a system is running.
If you want to build something and deliver it as a zip (the same way as the SDK), what you need to do is: 
a) build your thing,
b) export it with generated meta data and artifact repositories
c) install it using the director.app using a layout like the Eclipse SDK
d) zip the directory where you did the installation.
To make it "self managed" - you need to "include p2" in your application - which can mean including the same "machinery" and UI as in the Eclipse SDK, or that you create your own solution using the part of p2 that you need (i.e. your app does perhaps not need the advanced dialogs available in the SDK), 

There are (at least) two alternative ways of delivering your app;
1) instead of zipping an installed application, create the metadata and artifact repositories, and a separate installer (the p2-installer can be configured to install your app) - you then zip the repositories and the installer. The user unzips this, and then runs the installer which will install from the repositories that were included). 2) Just create the meta data and artifact repositories on your site, create a configuration of the p2-installer (or your own custom variation of such an installer), and zip only the p2-installer. The user downloads the installer, which will install from your update site. 

I hope this helps...

Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx



On Feb 26, 2009, at 11:23 AM, Fredrik Alströmer wrote:


Basically, what I want is for one p2 instance to convey information to
the system being installed about what IUs have been installed and so
on, so that it may update itself later on, when it's running. That's
what I mean with autonomous. Currently, when I use the p2-agent to
create a profile and install a product, the profile description ends
up in the profile registry of the agent, not in the directory created
of the created profile...

Given that this appears to be what is done with the eclipse sdk, it
should work. My second question was, is it possible to, with an
external p2 instance like the p2-agent, tap into this self contained
system and manage it (assuming it's not running of course)? This is
obviously true, I just need to make sure the p2-agent works with the
profile available in the installed system, rather than in its own
registry, the question is, how do I get the profile in there?

Thanks,
Fredrik.

On Thu, Feb 26, 2009 at 10:52, Haigermoser, Helmut
<Helmut.Haigermoser@xxxxxxxxxxxxx> wrote:

Ciao Frederik :)
Profiles can be "roaming", i.e. installable anywhere you want them to. Does that fit your definition of "autonomous"?
What happens under the hood is at first launch the profile will look at itself and it's current install dir and modify itself to fit the new place. That's how eclipse SDK manages to be distributable by zip and yet come with a complete profile... 

HTH,
Ciao, hh

-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev- bounces@xxxxxxxxxxx] On Behalf Of Fredrik Alströmer 
Sent: Thursday, February 26, 2009 10:46 AM
To: P2 developer discussions
Subject: Re: [p2-dev] Provisioning p2 with p2?
This is where I get lost, I understand that this might very well be the case (I found the profile registry in the p2 agent, which I'm using), but how would I go about to 'zip-up' my profile, which is done with the eclipse SDK as John described, and ship it off to somewhere else? Point being, I want my profile to be autonomous.
If I'm able to achieve this, would I still be able to use a second p2 agent to manage the now 'autonomous' system, as long as it's offline, or are these set-ups mutually exclusive (i.e. is an externally manageable autonomous system a contradiction in terms)? 

Thanks,
Fredrik.
On Thu, Feb 26, 2009 at 00:16, Henrik Lindberg <henrik.lindberg@xxxxxxxxxxxxxx > wrote: 
Hi,
The profiles are stored in a ProfileRegistry - and the implementation used in p2 stores the profiles under "engine". Snoop around under the "p2" 
directory in your stand alone Eclipse SDK installation, or under
user.home/.p2 if you tried a SharedInstall.

Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx



On Feb 25, 2009, at 4:47 PM, Fredrik Alströmer wrote:
Excellent, that's what I wanted to hear... Now I only need to figure 
out how to do this... ;)
For the second part, that's what I meant, I was just curious whether 
an external p2 system (which is creating the profile) is actually
able to convey information to the profile about IUs being installed
and so on. I wasn't able to find a meta data repository (i.e. a
description of the installed IUs) - only an artifact repository - in 
the profile I installed into, how does the p2 instance within the
created profile know what it contains? Or does it simply backtrack
and look for matching IUs to the artifacts?

Or am I simply missing some magic here? :)

Thanks,
Fredrik.

On Wed, Feb 25, 2009 at 15:01, John Arthorne
<John_Arthorne@xxxxxxxxxx>
wrote:


Absolutely, p2 can and does do that. In fact our Eclipse project
builds run exactly in this way - p2 ant tasks are used to create a
profile, into which the platform or Eclipse SDK is provisioned. The result is then zipped up and delivered on our downloads page. Also, 
once you have installed the platform (which includes p2), p2 will
manage and be able to upgrade that (including itself). p2 can manage 
a system that is not currently running, or it can manage a system
that it is currently running inside of.

What you read about who touches what might have been taken out of
context.
What that means is that if the user unzips stuff manually into
eclipse/plugins or eclipse/dropins, then it is the user's
responsibility to "manage" those plugins manually at the file system level (upgrade it, remove it, etc). p2 won't touch them. Things that 
have been provisioned into eclipse/plugins or elsewhere by p2 via
the user interface or command line tools shouldn't be manually
edited/removed at the file system level by the end user (just like
you don't manually move/delete DLL's from Windows apps and expect
them to continue working).




Fredrik Alströmer <roe@xxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

02/25/2009 08:38 AM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx> To p2- dev@xxxxxxxxxxx 
cc Subject [p2-dev] Provisioning p2 with p2?




Hi,

I think I read somewhere that, whatever is managed by p2 you
shouldn't touch, and whatever you manage p2 won't touch. This makes perfect sense, however there's one thing that's not completely clear 
to me. Is it one of the purposes of p2 to be able to create a new
profile (using p2, that is, like with the p2 agent), install p2 into 
that profile, and then let it manage itself?

Thanks,
Fredrik.
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev



_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev


_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev

Back to the top