> 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
> [EMAIL PROTECTED]
>
> 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
> > [EMAIL PROTECTED]
> >
> > 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@eclipse.org
> > https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
