Re: [p2-dev] Provisioning p2 with p2?

[Fredrik Alströmer <roe@xxxxxxx>]

Ok, thanks to all of you, I think I've got it now. Just one more
thing, is there a way to get the 'p2 disk layout' using standard
eclipse means (like, somewhere in the product export?), or would I
have to create and pack it up myself?

> Also note that external provisioning can be done while a system is running.

Should that read "can" or "can't"? Because from what I've heard, it's
always self-provisioning or provisioning of an external, non-running,
system. If it is indeed "can", how is the running system triggered to
update its enviroment? (by the way, in windows, bundles installed by
reference are locked and cannot be overwritten, wouldn't that be a
problem too?)

Thanks,
Fredrik.

On Thu, Feb 26, 2009 at 14:27, Henrik Lindberg
<henrik.lindberg@xxxxxxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
>