Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Writing custom P2 touchpoints
Writing custom P2 touchpoints [message #129561] Tue, 21 April 2009 14:51 Go to next message
Eclipse User
Originally posted by: mark_melvin.amis.com

Just out of curiosity, how easy is it to write a custom touchpoint?
Ideally we would probably look at extending the native touchpoint to make
a custom version (amongst others). We are basically trying to get our old
install handler code ported over to be called as a touchpoint.

Is there a doc somewhere outlining this? I have looked on the Wiki but
don't see anything like this. The closest I can come is this page:

http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal

It links to two bugs that both say they have been "fixed", but there is no
documentation or anything discussing how to use this feature.

Mark.
Re: Writing custom P2 touchpoints [message #129569 is a reply to message #129561] Tue, 21 April 2009 15:44 Go to previous messageGo to next message
Simon Kaegi is currently offline Simon Kaegi
Messages: 381
Registered: July 2009
Senior Member
Mark,

the functionality you're looking for has just recently committed to HEAD and
there will likely not be decent docs in place until we get time for this
sort of thing -- generally RC1/RC2.

For now I'd suggest taking a look at
http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as this is
likely to be a hub for the majority of the doc effort (at least on the wiki)
for this stuff.

Hopefully you would need to just write Actions instead of a full
touchpoint. If you're interested I'd dig into either the Eclipse or Native
Touchpoint as examples.

-Simon

"Mark Melvin" <mark_melvin@amis.com> wrote in message
news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
> Just out of curiosity, how easy is it to write a custom touchpoint?
> Ideally we would probably look at extending the native touchpoint to make
> a custom version (amongst others). We are basically trying to get our old
> install handler code ported over to be called as a touchpoint.
>
> Is there a doc somewhere outlining this? I have looked on the Wiki but
> don't see anything like this. The closest I can come is this page:
>
> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>
> It links to two bugs that both say they have been "fixed", but there is no
> documentation or anything discussing how to use this feature.
>
> Mark.
>
Re: Writing custom P2 touchpoints [message #129575 is a reply to message #129569] Tue, 21 April 2009 16:20 Go to previous messageGo to next message
Eclipse User
Originally posted by: mark_melvin.amis.com

Thanks, Simon. Can you give a pointer to some class names or at least
packages of interest in the source?

Also, what exactly is this "Install_Handler_Proposal". Is that the same
as the p2.inf - it seems different to me? Has that been implemented as
well? If so, where should I look for that source?

Finally, do you know if there is an easy way to author the metadata
outside of PDE build? For instance, is there an Ant task that will
convert a p2.inf file into metadata? My build process is fairly automated
right now, and I would really like to support P2 ideally by authoring some
files and generating as much as possible on my built artifacts.

Mark.


Simon Kaegi wrote:

> Mark,

> the functionality you're looking for has just recently committed to HEAD and
> there will likely not be decent docs in place until we get time for this
> sort of thing -- generally RC1/RC2.

> For now I'd suggest taking a look at
> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as this is
> likely to be a hub for the majority of the doc effort (at least on the wiki)
> for this stuff.

> Hopefully you would need to just write Actions instead of a full
> touchpoint. If you're interested I'd dig into either the Eclipse or Native
> Touchpoint as examples.

> -Simon

> "Mark Melvin" <mark_melvin@amis.com> wrote in message
> news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
>> Just out of curiosity, how easy is it to write a custom touchpoint?
>> Ideally we would probably look at extending the native touchpoint to make
>> a custom version (amongst others). We are basically trying to get our old
>> install handler code ported over to be called as a touchpoint.
>>
>> Is there a doc somewhere outlining this? I have looked on the Wiki but
>> don't see anything like this. The closest I can come is this page:
>>
>> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>>
>> It links to two bugs that both say they have been "fixed", but there is no
>> documentation or anything discussing how to use this feature.
>>
>> Mark.
>>
Re: Writing custom P2 touchpoints [message #129582 is a reply to message #129575] Tue, 21 April 2009 17:37 Go to previous messageGo to next message
Andrew Niefer is currently offline Andrew Niefer
Messages: 990
Registered: July 2009
Senior Member
Take a look at the hierachy of ProvisioningAction, most of the actions
are under org.eclipse.equinox.internal.p2.touchpoint.natives.actions or
org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.

There isn't any task that directly converts a p2.inf into metadata.
Currently the p2.inf is associated with some other input
feature/bundle/.product and there are ant tasks for publishing those
things. The simplest thing would probably be to create a feature to
contain the p2.inf and publish that.

-Andrew

Mark Melvin wrote:
> Thanks, Simon. Can you give a pointer to some class names or at least
> packages of interest in the source?
>
> Also, what exactly is this "Install_Handler_Proposal". Is that the same
> as the p2.inf - it seems different to me? Has that been implemented as
> well? If so, where should I look for that source?
>
> Finally, do you know if there is an easy way to author the metadata
> outside of PDE build? For instance, is there an Ant task that will
> convert a p2.inf file into metadata? My build process is fairly
> automated right now, and I would really like to support P2 ideally by
> authoring some files and generating as much as possible on my built
> artifacts.
>
> Mark.
>
>
> Simon Kaegi wrote:
>
>> Mark,
>
>> the functionality you're looking for has just recently committed to
>> HEAD and there will likely not be decent docs in place until we get
>> time for this sort of thing -- generally RC1/RC2.
>
>> For now I'd suggest taking a look at
>> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as
>> this is likely to be a hub for the majority of the doc effort (at
>> least on the wiki) for this stuff.
>
>> Hopefully you would need to just write Actions instead of a full
>> touchpoint. If you're interested I'd dig into either the Eclipse or
>> Native Touchpoint as examples.
>
>> -Simon
>
>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>> news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
>>> Just out of curiosity, how easy is it to write a custom touchpoint?
>>> Ideally we would probably look at extending the native touchpoint to
>>> make a custom version (amongst others). We are basically trying to
>>> get our old install handler code ported over to be called as a
>>> touchpoint.
>>>
>>> Is there a doc somewhere outlining this? I have looked on the Wiki
>>> but don't see anything like this. The closest I can come is this page:
>>>
>>> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>>>
>>> It links to two bugs that both say they have been "fixed", but there
>>> is no documentation or anything discussing how to use this feature.
>>>
>>> Mark.
>>>
>
Re: Writing custom P2 touchpoints [message #129695 is a reply to message #129582] Wed, 22 April 2009 09:46 Go to previous messageGo to next message
Eclipse User
Originally posted by: mark_melvin.amis.com

Thanks, Andrew. I'm looking at the source now. I have some more
questions, if you don't mind:

1) What is the touchpoint 'type' used for, and why are they all
"org.eclipse.equinox.p2.osgi". It looks like this is just a category for
book-keeping purposes and isn't really used for anything yet. Should I
make up my own type, or use "org.eclipse.equinox.p2.osgi"?

2) I keep reading about a p2.flavor in concert with metadata generation,
and it is always "tooling". What is this used for? Are there any other
flavors (I like cherry...)?

3) Has anything been done to address the fact that in order to provide
custom install behavior (i.e. my own touchpoint Actions) I need to first
install and activate my custom Action into whatever codebase is backing
the director first? With the old update manager we used to have to do a
two-pass installation into the platform (it was invisible in the
installer, but a real pain when updating via an update site) where the
first pass would update the install handler engine, and the second pass
would update everything else. Is there a way around this in P2? If the
code behind my custom touchpoint Actions is updated, I'll still need to do
a two-pass update (i.e. search for updates, install touchpoint action
update, restart, search for updates, install the rest of my updates,
restart) correct?

Related to this point, I just noticed that the "Install_Handler_Proposal"
wiki page - which attempts to address this issue has an "Obsolete" at the
top. That seems to have been added recently. Does this mean this never
went anywhere? There is talk in bug #257792 about code in a branch - was
this abandoned?

It would be cool if P2 was smart enough to install any custom touchpoint
Action extensions first, then proceed with the rest of the updates.

Thanks again,
Mark.

Andrew Niefer wrote:

> Take a look at the hierachy of ProvisioningAction, most of the actions
> are under org.eclipse.equinox.internal.p2.touchpoint.natives.actions or
> org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.

> There isn't any task that directly converts a p2.inf into metadata.
> Currently the p2.inf is associated with some other input
> feature/bundle/.product and there are ant tasks for publishing those
> things. The simplest thing would probably be to create a feature to
> contain the p2.inf and publish that.

> -Andrew

> Mark Melvin wrote:
>> Thanks, Simon. Can you give a pointer to some class names or at least
>> packages of interest in the source?
>>
>> Also, what exactly is this "Install_Handler_Proposal". Is that the same
>> as the p2.inf - it seems different to me? Has that been implemented as
>> well? If so, where should I look for that source?
>>
>> Finally, do you know if there is an easy way to author the metadata
>> outside of PDE build? For instance, is there an Ant task that will
>> convert a p2.inf file into metadata? My build process is fairly
>> automated right now, and I would really like to support P2 ideally by
>> authoring some files and generating as much as possible on my built
>> artifacts.
>>
>> Mark.
>>
>>
>> Simon Kaegi wrote:
>>
>>> Mark,
>>
>>> the functionality you're looking for has just recently committed to
>>> HEAD and there will likely not be decent docs in place until we get
>>> time for this sort of thing -- generally RC1/RC2.
>>
>>> For now I'd suggest taking a look at
>>> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as
>>> this is likely to be a hub for the majority of the doc effort (at
>>> least on the wiki) for this stuff.
>>
>>> Hopefully you would need to just write Actions instead of a full
>>> touchpoint. If you're interested I'd dig into either the Eclipse or
>>> Native Touchpoint as examples.
>>
>>> -Simon
>>
>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>> news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
>>>> Just out of curiosity, how easy is it to write a custom touchpoint?
>>>> Ideally we would probably look at extending the native touchpoint to
>>>> make a custom version (amongst others). We are basically trying to
>>>> get our old install handler code ported over to be called as a
>>>> touchpoint.
>>>>
>>>> Is there a doc somewhere outlining this? I have looked on the Wiki
>>>> but don't see anything like this. The closest I can come is this page:
>>>>
>>>> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>>>>
>>>> It links to two bugs that both say they have been "fixed", but there
>>>> is no documentation or anything discussing how to use this feature.
>>>>
>>>> Mark.
>>>>
>>
Re: Writing custom P2 touchpoints [message #129703 is a reply to message #129695] Wed, 22 April 2009 10:46 Go to previous messageGo to next message
Andrew Niefer is currently offline Andrew Niefer
Messages: 990
Registered: July 2009
Senior Member
1) The type corresponds to the TouchPoint, it is defined in the
plugin.xml for the "org.eclipse.equinox.p2.engine.touchpoints" extension
point. "org.eclipse.equinox.p2.osgi" is the EclipseTouchpoint.

Simon will know more about what to do here if you aren't doing a full
touchpoint but are just writing actions. (Though it looks like the
action extension point specifies what Touchpoint to contribute to).

2) I'm not sure that the flavor is used for anything outside of metadata
generation where it serves as a kind of qualifier on the configuration
units generated for a product. This allows different "flavors" of a
product to have different configurations (start levels, etc).

3) There is a new "meta" requirement that IUs can have that does this I
think. Simon will know the details.

-Andrew
Mark Melvin wrote:
> Thanks, Andrew. I'm looking at the source now. I have some more
> questions, if you don't mind:
>
> 1) What is the touchpoint 'type' used for, and why are they all
> "org.eclipse.equinox.p2.osgi". It looks like this is just a category
> for book-keeping purposes and isn't really used for anything yet.
> Should I make up my own type, or use "org.eclipse.equinox.p2.osgi"?
>
> 2) I keep reading about a p2.flavor in concert with metadata generation,
> and it is always "tooling". What is this used for? Are there any other
> flavors (I like cherry...)?
>
> 3) Has anything been done to address the fact that in order to provide
> custom install behavior (i.e. my own touchpoint Actions) I need to first
> install and activate my custom Action into whatever codebase is backing
> the director first? With the old update manager we used to have to do a
> two-pass installation into the platform (it was invisible in the
> installer, but a real pain when updating via an update site) where the
> first pass would update the install handler engine, and the second pass
> would update everything else. Is there a way around this in P2? If the
> code behind my custom touchpoint Actions is updated, I'll still need to
> do a two-pass update (i.e. search for updates, install touchpoint action
> update, restart, search for updates, install the rest of my updates,
> restart) correct?
>
> Related to this point, I just noticed that the
> "Install_Handler_Proposal" wiki page - which attempts to address this
> issue has an "Obsolete" at the top. That seems to have been added
> recently. Does this mean this never went anywhere? There is talk in
> bug #257792 about code in a branch - was this abandoned?
>
> It would be cool if P2 was smart enough to install any custom touchpoint
> Action extensions first, then proceed with the rest of the updates.
>
> Thanks again,
> Mark.
>
> Andrew Niefer wrote:
>
>> Take a look at the hierachy of ProvisioningAction, most of the actions
>> are under org.eclipse.equinox.internal.p2.touchpoint.natives.actions or
>> org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.
>
>> There isn't any task that directly converts a p2.inf into metadata.
>> Currently the p2.inf is associated with some other input
>> feature/bundle/.product and there are ant tasks for publishing those
>> things. The simplest thing would probably be to create a feature to
>> contain the p2.inf and publish that.
>
>> -Andrew
>
>> Mark Melvin wrote:
>>> Thanks, Simon. Can you give a pointer to some class names or at
>>> least packages of interest in the source?
>>>
>>> Also, what exactly is this "Install_Handler_Proposal". Is that the
>>> same as the p2.inf - it seems different to me? Has that been
>>> implemented as well? If so, where should I look for that source?
>>>
>>> Finally, do you know if there is an easy way to author the metadata
>>> outside of PDE build? For instance, is there an Ant task that will
>>> convert a p2.inf file into metadata? My build process is fairly
>>> automated right now, and I would really like to support P2 ideally by
>>> authoring some files and generating as much as possible on my built
>>> artifacts.
>>>
>>> Mark.
>>>
>>>
>>> Simon Kaegi wrote:
>>>
>>>> Mark,
>>>
>>>> the functionality you're looking for has just recently committed to
>>>> HEAD and there will likely not be decent docs in place until we get
>>>> time for this sort of thing -- generally RC1/RC2.
>>>
>>>> For now I'd suggest taking a look at
>>>> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as
>>>> this is likely to be a hub for the majority of the doc effort (at
>>>> least on the wiki) for this stuff.
>>>
>>>> Hopefully you would need to just write Actions instead of a full
>>>> touchpoint. If you're interested I'd dig into either the Eclipse or
>>>> Native Touchpoint as examples.
>>>
>>>> -Simon
>>>
>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>> news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
>>>>> Just out of curiosity, how easy is it to write a custom touchpoint?
>>>>> Ideally we would probably look at extending the native touchpoint
>>>>> to make a custom version (amongst others). We are basically trying
>>>>> to get our old install handler code ported over to be called as a
>>>>> touchpoint.
>>>>>
>>>>> Is there a doc somewhere outlining this? I have looked on the Wiki
>>>>> but don't see anything like this. The closest I can come is this
>>>>> page:
>>>>>
>>>>> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>>>>>
>>>>> It links to two bugs that both say they have been "fixed", but
>>>>> there is no documentation or anything discussing how to use this
>>>>> feature.
>>>>>
>>>>> Mark.
>>>>>
>>>
>
Re: Writing custom P2 touchpoints [message #129711 is a reply to message #129703] Wed, 22 April 2009 11:04 Go to previous messageGo to next message
Eclipse User
Originally posted by: mark_melvin.amis.com

OK - cool. Thanks for the information, Andrew - I appreciate it!
Hopefully Simon will chime in on the rest.

Regards,
Mark.

Andrew Niefer wrote:

> 1) The type corresponds to the TouchPoint, it is defined in the
> plugin.xml for the "org.eclipse.equinox.p2.engine.touchpoints" extension
> point. "org.eclipse.equinox.p2.osgi" is the EclipseTouchpoint.

> Simon will know more about what to do here if you aren't doing a full
> touchpoint but are just writing actions. (Though it looks like the
> action extension point specifies what Touchpoint to contribute to).

> 2) I'm not sure that the flavor is used for anything outside of metadata
> generation where it serves as a kind of qualifier on the configuration
> units generated for a product. This allows different "flavors" of a
> product to have different configurations (start levels, etc).

> 3) There is a new "meta" requirement that IUs can have that does this I
> think. Simon will know the details.

> -Andrew
> Mark Melvin wrote:
>> Thanks, Andrew. I'm looking at the source now. I have some more
>> questions, if you don't mind:
>>
>> 1) What is the touchpoint 'type' used for, and why are they all
>> "org.eclipse.equinox.p2.osgi". It looks like this is just a category
>> for book-keeping purposes and isn't really used for anything yet.
>> Should I make up my own type, or use "org.eclipse.equinox.p2.osgi"?
>>
>> 2) I keep reading about a p2.flavor in concert with metadata generation,
>> and it is always "tooling". What is this used for? Are there any other
>> flavors (I like cherry...)?
>>
>> 3) Has anything been done to address the fact that in order to provide
>> custom install behavior (i.e. my own touchpoint Actions) I need to first
>> install and activate my custom Action into whatever codebase is backing
>> the director first? With the old update manager we used to have to do a
>> two-pass installation into the platform (it was invisible in the
>> installer, but a real pain when updating via an update site) where the
>> first pass would update the install handler engine, and the second pass
>> would update everything else. Is there a way around this in P2? If the
>> code behind my custom touchpoint Actions is updated, I'll still need to
>> do a two-pass update (i.e. search for updates, install touchpoint action
>> update, restart, search for updates, install the rest of my updates,
>> restart) correct?
>>
>> Related to this point, I just noticed that the
>> "Install_Handler_Proposal" wiki page - which attempts to address this
>> issue has an "Obsolete" at the top. That seems to have been added
>> recently. Does this mean this never went anywhere? There is talk in
>> bug #257792 about code in a branch - was this abandoned?
>>
>> It would be cool if P2 was smart enough to install any custom touchpoint
>> Action extensions first, then proceed with the rest of the updates.
>>
>> Thanks again,
>> Mark.
>>
>> Andrew Niefer wrote:
>>
>>> Take a look at the hierachy of ProvisioningAction, most of the actions
>>> are under org.eclipse.equinox.internal.p2.touchpoint.natives.actions or
>>> org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.
>>
>>> There isn't any task that directly converts a p2.inf into metadata.
>>> Currently the p2.inf is associated with some other input
>>> feature/bundle/.product and there are ant tasks for publishing those
>>> things. The simplest thing would probably be to create a feature to
>>> contain the p2.inf and publish that.
>>
>>> -Andrew
>>
>>> Mark Melvin wrote:
>>>> Thanks, Simon. Can you give a pointer to some class names or at
>>>> least packages of interest in the source?
>>>>
>>>> Also, what exactly is this "Install_Handler_Proposal". Is that the
>>>> same as the p2.inf - it seems different to me? Has that been
>>>> implemented as well? If so, where should I look for that source?
>>>>
>>>> Finally, do you know if there is an easy way to author the metadata
>>>> outside of PDE build? For instance, is there an Ant task that will
>>>> convert a p2.inf file into metadata? My build process is fairly
>>>> automated right now, and I would really like to support P2 ideally by
>>>> authoring some files and generating as much as possible on my built
>>>> artifacts.
>>>>
>>>> Mark.
>>>>
>>>>
>>>> Simon Kaegi wrote:
>>>>
>>>>> Mark,
>>>>
>>>>> the functionality you're looking for has just recently committed to
>>>>> HEAD and there will likely not be decent docs in place until we get
>>>>> time for this sort of thing -- generally RC1/RC2.
>>>>
>>>>> For now I'd suggest taking a look at
>>>>> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as
>>>>> this is likely to be a hub for the majority of the doc effort (at
>>>>> least on the wiki) for this stuff.
>>>>
>>>>> Hopefully you would need to just write Actions instead of a full
>>>>> touchpoint. If you're interested I'd dig into either the Eclipse or
>>>>> Native Touchpoint as examples.
>>>>
>>>>> -Simon
>>>>
>>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>>> news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
>>>>>> Just out of curiosity, how easy is it to write a custom touchpoint?
>>>>>> Ideally we would probably look at extending the native touchpoint
>>>>>> to make a custom version (amongst others). We are basically trying
>>>>>> to get our old install handler code ported over to be called as a
>>>>>> touchpoint.
>>>>>>
>>>>>> Is there a doc somewhere outlining this? I have looked on the Wiki
>>>>>> but don't see anything like this. The closest I can come is this
>>>>>> page:
>>>>>>
>>>>>> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>>>>>>
>>>>>> It links to two bugs that both say they have been "fixed", but
>>>>>> there is no documentation or anything discussing how to use this
>>>>>> feature.
>>>>>>
>>>>>> Mark.
>>>>>>
>>>>
>>
Re: Writing custom P2 touchpoints [message #129768 is a reply to message #129695] Thu, 23 April 2009 00:00 Go to previous messageGo to next message
Simon Kaegi is currently offline Simon Kaegi
Messages: 381
Registered: July 2009
Senior Member
> 1) What is the touchpoint 'type' used for, and why are they all
> "org.eclipse.equinox.p2.osgi". It looks like this is just a category for
> book-keeping purposes and isn't really used for anything yet. Should I
> make up my own type, or use "org.eclipse.equinox.p2.osgi"?

Most of our actions depend on certain variables that are set in the
touchpoint. For example the eclipse touchpoint sets a {manipulator} variable
that's used to handle writing most of eclipse's configuration files. Many of
the actions that are in the eclipse touchpoint bundle make use of the
{manipulator} to perform tasks like installing bundles and the like. If your
action is going to use these variable then you need to specify a touchpoint
type to ensure that everything is initialized before your action runs.

For the more typical case of a self contained custom action you generally
shouldn't need to declare a touchpoint type.
>
> 2) I keep reading about a p2.flavor in concert with metadata generation,
> and it is always "tooling". What is this used for? Are there any other
> flavors (I like cherry...)?
>
For now you can ignore it.

> 3) Has anything been done to address the fact that in order to provide
> custom install behavior (i.e. my own touchpoint Actions) I need to first
> install and activate my custom Action into whatever codebase is backing
> the director first? With the old update manager we used to have to do a
> two-pass installation into the platform (it was invisible in the
> installer, but a real pain when updating via an update site) where the
> first pass would update the install handler engine, and the second pass
> would update everything else. Is there a way around this in P2? If the
> code behind my custom touchpoint Actions is updated, I'll still need to do
> a two-pass update (i.e. search for updates, install touchpoint action
> update, restart, search for updates, install the rest of my updates,
> restart) correct?
>
> Related to this point, I just noticed that the "Install_Handler_Proposal"
> wiki page - which attempts to address this issue has an "Obsolete" at the
> top. That seems to have been added recently. Does this mean this never
> went anywhere? There is talk in bug #257792 about code in a branch - was
> this abandoned?
>
> It would be cool if P2 was smart enough to install any custom touchpoint
> Action extensions first, then proceed with the rest of the updates.
>
As luck would have it a solution to this problem this was recently committed
to HEAD.

We now support a two-stage plan that does it all in one-shot. This is
bleeding edge stuff but in a nutshell you declare a "metaRequirement" (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=271342) on the custom action
in the bundle where you're using it.

Currently you can do this with the META-INF/p2.inf file with something like:
--{Bundle1}
metaRequirements.0.namespace=org.eclipse.equinox.p2.engine.a ctions
metaRequirements.0.name=dummy.touchpointAndAction.dummy
metaRequirements.0.range=1.0
instructions.configure=dummy.touchpointAndAction.dummy();
--

Likewise in your bundle that is providing the actions you use the p2.inf to
provide the new capability:
--{Bundle2}
provides.0.namespace=org.eclipse.equinox.p2.engine.actions
provides.0.name=dummy.touchpointAndAction.dummy
provides.0.version=1.0
--

Now, the support I mentioned that was recently added in HEAD makes it so
thatwhen you go to install Bundle 1, Bundle 2 will get dragged in by the
"metaRequirements" and get installed first before installing and configuring
Bundle2.

I'll attach the two bundle projects so you can see a rough setup. Docs for
this stuff are still being worked on however if you want to get a better
feel for what's going on at runtime export the two bundles and (I can't
believe I'm saying this) put them in dropins and restart with a remote
debugger attached.

We're pretty time limited for the next little bit but by all means ask
questions and I'll do my best to answer when I can find a spare moment.

HTH
-Simon

> Thanks again,
> Mark.
>
> Andrew Niefer wrote:
>
>> Take a look at the hierachy of ProvisioningAction, most of the actions
>> are under org.eclipse.equinox.internal.p2.touchpoint.natives.actions or
>> org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.
>
>> There isn't any task that directly converts a p2.inf into metadata.
>> Currently the p2.inf is associated with some other input
>> feature/bundle/.product and there are ant tasks for publishing those
>> things. The simplest thing would probably be to create a feature to
>> contain the p2.inf and publish that.
>
>> -Andrew
>
>> Mark Melvin wrote:
>>> Thanks, Simon. Can you give a pointer to some class names or at least
>>> packages of interest in the source?
>>>
>>> Also, what exactly is this "Install_Handler_Proposal". Is that the same
>>> as the p2.inf - it seems different to me? Has that been implemented as
>>> well? If so, where should I look for that source?
>>>
>>> Finally, do you know if there is an easy way to author the metadata
>>> outside of PDE build? For instance, is there an Ant task that will
>>> convert a p2.inf file into metadata? My build process is fairly
>>> automated right now, and I would really like to support P2 ideally by
>>> authoring some files and generating as much as possible on my built
>>> artifacts.
>>>
>>> Mark.
>>>
>>>
>>> Simon Kaegi wrote:
>>>
>>>> Mark,
>>>
>>>> the functionality you're looking for has just recently committed to
>>>> HEAD and there will likely not be decent docs in place until we get
>>>> time for this sort of thing -- generally RC1/RC2.
>>>
>>>> For now I'd suggest taking a look at
>>>> http://wiki.eclipse.org/Equinox/p2/Engine/Touchpoint_Instruc tions as
>>>> this is likely to be a hub for the majority of the doc effort (at
>>>> least on the wiki) for this stuff.
>>>
>>>> Hopefully you would need to just write Actions instead of a full
>>>> touchpoint. If you're interested I'd dig into either the Eclipse or
>>>> Native Touchpoint as examples.
>>>
>>>> -Simon
>>>
>>>> "Mark Melvin" <mark_melvin@amis.com> wrote in message
>>>> news:b9d880a357affccfbd2d928b7ac1bcbf$1@www.eclipse.org...
>>>>> Just out of curiosity, how easy is it to write a custom touchpoint?
>>>>> Ideally we would probably look at extending the native touchpoint to
>>>>> make a custom version (amongst others). We are basically trying to
>>>>> get our old install handler code ported over to be called as a
>>>>> touchpoint.
>>>>>
>>>>> Is there a doc somewhere outlining this? I have looked on the Wiki
>>>>> but don't see anything like this. The closest I can come is this
>>>>> page:
>>>>>
>>>>> http://wiki.eclipse.org/Equinox/p2/Proposals/Install_Handler _Proposal
>>>>>
>>>>> It links to two bugs that both say they have been "fixed", but there
>>>>> is no documentation or anything discussing how to use this feature.
>>>>>
>>>>> Mark.
>>>>>
>>>
>


Re: Writing custom P2 touchpoints [message #129797 is a reply to message #129768] Thu, 23 April 2009 09:52 Go to previous message
Eclipse User
Originally posted by: mark_melvin.amis.com

Thank you, Simon (and Andrew!) - this is very useful information. We'd
really like to move to P2 this year, as we have not missed an upgrade yet
(although we had to rip out P2 last year). It looks like it has come a
long way. I just hope I can refactor our build and installer in time.
I'll be sure to file any issues I find.

Mark.

Simon Kaegi wrote:

>> 1) What is the touchpoint 'type' used for, and why are they all
>> "org.eclipse.equinox.p2.osgi". It looks like this is just a category for
>> book-keeping purposes and isn't really used for anything yet. Should I
>> make up my own type, or use "org.eclipse.equinox.p2.osgi"?

> Most of our actions depend on certain variables that are set in the
> touchpoint. For example the eclipse touchpoint sets a {manipulator} variable
> that's used to handle writing most of eclipse's configuration files. Many of
> the actions that are in the eclipse touchpoint bundle make use of the
> {manipulator} to perform tasks like installing bundles and the like. If your
> action is going to use these variable then you need to specify a touchpoint
> type to ensure that everything is initialized before your action runs.

> For the more typical case of a self contained custom action you generally
> shouldn't need to declare a touchpoint type.
>>
>> 2) I keep reading about a p2.flavor in concert with metadata generation,
>> and it is always "tooling". What is this used for? Are there any other
>> flavors (I like cherry...)?
>>
> For now you can ignore it.

>> 3) Has anything been done to address the fact that in order to provide
>> custom install behavior (i.e. my own touchpoint Actions) I need to first
>> install and activate my custom Action into whatever codebase is backing
>> the director first? With the old update manager we used to have to do a
>> two-pass installation into the platform (it was invisible in the
>> installer, but a real pain when updating via an update site) where the
>> first pass would update the install handler engine, and the second pass
>> would update everything else. Is there a way around this in P2? If the
>> code behind my custom touchpoint Actions is updated, I'll still need to do
>> a two-pass update (i.e. search for updates, install touchpoint action
>> update, restart, search for updates, install the rest of my updates,
>> restart) correct?
>>
>> Related to this point, I just noticed that the "Install_Handler_Proposal"
>> wiki page - which attempts to address this issue has an "Obsolete" at the
>> top. That seems to have been added recently. Does this mean this never
>> went anywhere? There is talk in bug #257792 about code in a branch - was
>> this abandoned?
>>
>> It would be cool if P2 was smart enough to install any custom touchpoint
>> Action extensions first, then proceed with the rest of the updates.
>>
> As luck would have it a solution to this problem this was recently committed
> to HEAD.

> We now support a two-stage plan that does it all in one-shot. This is
> bleeding edge stuff but in a nutshell you declare a "metaRequirement" (see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=271342) on the custom action
> in the bundle where you're using it.

> Currently you can do this with the META-INF/p2.inf file with something like:
> --{Bundle1}
> metaRequirements.0.namespace=org.eclipse.equinox.p2.engine.a ctions
> metaRequirements.0.name=dummy.touchpointAndAction.dummy
> metaRequirements.0.range=1.0
> instructions.configure=dummy.touchpointAndAction.dummy();
> --

> Likewise in your bundle that is providing the actions you use the p2.inf to
> provide the new capability:
> --{Bundle2}
> provides.0.namespace=org.eclipse.equinox.p2.engine.actions
> provides.0.name=dummy.touchpointAndAction.dummy
> provides.0.version=1.0
> --

> Now, the support I mentioned that was recently added in HEAD makes it so
> thatwhen you go to install Bundle 1, Bundle 2 will get dragged in by the
> "metaRequirements" and get installed first before installing and configuring
> Bundle2.

> I'll attach the two bundle projects so you can see a rough setup. Docs for
> this stuff are still being worked on however if you want to get a better
> feel for what's going on at runtime export the two bundles and (I can't
> believe I'm saying this) put them in dropins and restart with a remote
> debugger attached.

> We're pretty time limited for the next little bit but by all means ask
> questions and I'll do my best to answer when I can find a spare moment.

> HTH
> -Simon
Previous Topic:Update Hook Adapter fragment
Next Topic:[p2] Default repository
Goto Forum:
  


Current Time: Fri Jul 25 13:46:29 EDT 2014

Powered by FUDForum. Page generated in 0.02449 seconds