| Well, I can do it that way too - I will then show a tree of "instruction blocks" where each block as the nodes "install/uninstall/configure..." already in place, but empty if there are no instructions. Then the user can either add a new "instruction block" or add/edit actions in the nodes. Empty nodes will not be written to XML.
It would be good if it was possible to give the TouchpointData a name/label - this if an IU has several and user wants to name them to be able to find the wanted block without browsing through instructions. Meanwhile I will just label them "instruction block n" or something like that.
Is that better?
On 24 jun 2008, at 16.13, Simon Kaegi wrote:
> Does it matter if an IU is authored so that there is only one
> instruction per TouchpointData? This would make it easier in the
> user interface. The user would then only see two levels - the
> instruction (install, uninstall, etc.), and the actions for the
> instruction. The grouping of several instructions seems to have no
> semantic meaning (but is useful at runtime).
>
> Thus, the user can add install, uninstall, etc. instructions, and
> add actions to them but do not have to be concerned with grouping at all.
> Do you think this approach is ok?
The implementation would support this however I personally find it a bit fine grained.
I tend to group contributions around installing/configuring/uninstalling etc. a particular artifact.
In other words the semantics I apply are along the lines of...
...these are the instructions for this chunk of touchpoint data (e.g. artifact).
With that said, I'm not too fussed about it.
-Simon
>
> Regards
> Henrik Lindberg
> henrik.lindberg@xxxxxxxxxxxxxx
>
> On 23 jun 2008, at 21.40, Simon Kaegi wrote:
>
> > 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
> _______________________________________________
> 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
|
