| Re: [equinox-dev] P2 touchpoint instructions doc |
> Hm, I think may able to answer this myself. The format is actually
> documented :)
>
> The touchpoint data has a map, the keys in this map are the phases
> like "install", and the value is the format described on the wiki
> page - i.e. a string that needs to be parsed
> to understand the actions and parameters i.e "action1
> (paramname1:value, paramname2:value, paramname3:value);action2(...); ..."
>
> Can someone confirm - or have I got it wrong yet one more time :) ?
Yep. That's it. You've got it.
>
> Henrik Lindberg
> henrik.lindberg@xxxxxxxxxxxxxx
>
> On 23 jun 2008, at 17.25, Henrik Lindberg wrote:
>
> Thanks Simon,
> Hm, seems that my understanding of this is still unclear. I
> understand touchpoint type - one IU can affect one touchpoint only,
> but I have trouble with Touchpoint Data.
> The IU has a list of Touchpoint Data. What exactly is one such
> Touchpoint Data instance describing? I thought it was one
> instruction like "chmod", but now I am uncertain. From your response
> it seems like one Touchpoint Data instance describes a set of
> instructions for a phase like "install" - or is it even capable of
> describing multiple sets of instructions for different phases?
>
> Is the following correct touchpoint data?
>
> touchpoint data = a Map {
> { key = "install", value= a Map {
> {key=setXXX, value= aMap { {key=param1, value="" } {key=param2, value=""}},
> {key=chmod, value= aMap { {key=param1, value="" } {key=param2, value=""}} }
> { key = uninstall, value= a Map {
> // instructions for uninstall...
> } }
> }
>
> If that is true, then I will update the wiki page to make it clear -
> an "instruction" is the top level thing (i.e. "install",
> "uninstall"), and in such an instruction it is possible to specify
> actions (but only one action instance per type of action).
>
> Henrik Lindberg
> henrik.lindberg@xxxxxxxxxxxxxx
>
> On 23 jun 2008, at 16.27, Simon Kaegi wrote:
>
>
> > A couple of notes and questions:
> > - With the current encoding (a map of instructions), it is not
> > possible to use the same instruction type more than once. Is this
> > intentional? What if the author needs to create two directories etc?
> > (I am asking because if this will be changed in the future I want to
> > allow the user to add more than one of the same instruction type).
>
> At runtime the intent is to allow a "resolved" IU to provide
> multiple instructions with the same key. e.g. multiple "install"
> instructions is fair game.
> I use "runtime" and "resolved" because one of the important uses of
> multiple instructions is to allow IUFragments to provide additional
> instructions with the same key.
> e.g. an IU when resolved with IUFragments might provide multiple
> "install" instructions.
>
> At dev time I would suggest only using one instruction for each key
> although I don't believe there is a formal restriction here.
>
> > I think I may have understood the format wrong. Does an instance of
> > TouchpointData describe one instruction?
>
> Multiple instructions are fine... e.g. an IU's touchpoint data
> section can provide an "install", "uninstall", "configure", etc. set
> of instructions.
>
> > - Why the special use of "@artifact" instead of an injected
> > parameter like "artifactDir" that can be included with $
> > {artifactDir} ? (I am asking because I am thinking about what kind
> > of editing support to offer - perhaps browse/select from available
> > parameters, and the @artifact is different than the other parameters).
>
> Yes this is something we can cleanup. Originally we didn't have a
> place to initialize parameters that would get set by an action from
> an earlier phase.
> There are a few other changes that need to be done here also to
> allow referencing more than just the first artifact of an IU. As a
> result I was reluctant to do a change here late in the cycle.
>
> > - How are actions executed during the phases? (I have not studied
> > the code), but it seems logical that what is specified in the IU's
> > touchpoint data gets executed during install and uninstall - and
> > that the install phase executes the Action's "execute" the
> > uninstall executes the Action's "undo" - is this correct?
>
> Undo is used "only" when rolling back a failed set of operations.
> e.g. during the uninstall phase we use explicit uninstallbundle actions.
> The reason this is the case is that an action/undo pair is not
> always perfectly symmetric e.g. an action can be destructive (for
> example over-writing a program argument). In these cases the actions
> "undo" can restore from a saved memento.
>
> -Simon
>
> >
> > Henrik Lindberg
> > henrik.lindberg@xxxxxxxxxxxxxx
> >
> > On 20 jun 2008, at 04.56, Simon Kaegi wrote:
> >
> > > I have now written a wiki page: http://wiki.eclipse.org/
> > > Equinox_p2_Touchpoint_Instructions describing the touchpoint
> > > instructions for the native and eclipse touchpoints, their
> > > parameters, and how I think it works after reading the code. There
> > > are places where I need help (indicated by blue comment boxes), but
> > > I may have gotten other things wrong as well.
> > >
> > > It is probably of value to also describe the parameters inserted by
> > > the engine as these can be used in parameter substitution. I don't
> > > know if it is intended, but it seems very powerful to be able to
> > > reference the "previous value". Shall I just make a list of what I
> > > find, and include it?
> > >
> > > So, I hope someone has time to review and comment on the
> > > documentation on the wiki page.
> >
> > Great job.
> > I'll go through and review tomorrow.
> > While reading through I recognized there is some overlap with an
> > earlier page -- http://wiki.eclipse.org/Equinox_p2_Engine
> > Your presentation is vastly better and easier to understand so I'll
> > go through and do some merging/updating/re-organizing of that content.
> >
> > Thanks.
> > -Simon
> >
> > >
> > > Regards
> > >
> > > Henrik Lindberg
> > > henrik.lindberg@xxxxxxxxxxxxxx
> > >
> > > On 18 jun 2008, at 19.13, Simon Kaegi wrote:
> > >
> > > > - How can I learn what the input to the actions are? Some parameters
> > > > look like they are provided by the runtime (i.e. not specified in the
> > > > iu touchpoint data). If there is no documentation, I can write up a
> > > > list of what I think the parameter are and ask for someone to review.
> > >
> > > That would be incredibly appreciated.
> > > _______________________________________________
> > > equinox-dev mailing list
> > > equinox-dev@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> > _______________________________________________
> > equinox-dev mailing list
> > equinox-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev