[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [p2-dev] Provisioning p2 with p2?
|
Hi again,
I've played around a bit more with it, but I'm still stuck on the fact
that the p2 data area always end up within the installer or agent
directories, how would I go about transferring the data area to the
product being installed? (The config.ini even gets an absolute path to
the data area of the installer, which is kind of ugly)
This might be a dumb question, and obvious to everyone involved, but
I'm lost! :)
Thanks,
Fredrik.
On Fri, Mar 6, 2009 at 13:12, Fredrik Alströmer <roe@xxxxxxx> wrote:
> 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
>>
>
