| Re: [equinox-dev] P2 metadata authoring - status/questions |
> Hi,
> I have been working on p2 meta data authoring, and have created a
> large part of an Installable Unit editor.
>
> As I did not want to lose the code in case of disaster, I checked it
> in to the Buckminster SVN in wait for the proper place to be created
That's great. Is it in a workable state that we could try out? What's the CVS path.
> (understand everyone is busy with Ganymede stuff, so no need to hurry
> - I am not blocked by this).
>
> I am however a bit blocked by not understanding touchpoints and
> touchpoint data, and what should be done about them from an authoring
> perspective. So... here is a bunch of questions that I hope someone
> has time to answer:
>
> - If an IU does not have any touchpoint data is the default then
> NullTouchpoint or must the null touchpoint be set explicitly?
Currently, each IU must set a touchpoint type - e.g. no default is set.
Having no touchpoint data on the other-hand is fine although this means no actions will be run for the IU.
> - The touchpoint type has a version. Does it denote the version of the
> touchpoint data, or is it used by a matching strategy to find a
> particular version of a Touchpoint instance at runtime?
The latter e.g. the version is used to find the appropriate Touchpoint instance.
> I have looked at the touchpoint data/touchpoint actions, and I
> understand that there are 5 actions for the native touchpoint (cleanup
> zip, unzip, chmod, collect, link), and 21 (collect, bundle: install/
> uninstall/add-source/remove-source, feature: install/uninstall, set
> launcher, program argument: add/remove, set start level, mark started,
> set FW dependent/independent property, add JVM argument, mkdir, rmdir,
> link, chmod, check trust). I understand that the set of actions can
> change over time (hence the version on touchpoint type?), and also
> understand that it is possible to add new types of touchpoints. My
> idea was therefore to support touchpoint data authoring via an
> extension point that allows the provider of a touchpoint to provide
> information how they should be edited - i.e. the set of touchpoint
> data key's and what values they can have, and validators.
>
> Now some more questions:
> - Do you think it makes sense to be able to edit all of these, or are
> some of the instructions generated (like check trust?)
In an editor sure. If we really need to perform a mandatory check we can do that when the touchpoint interprets the actions.
> - 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.
> - Since the touchpoint data is open ended it needs to handle any type
> of data. Is it correct that it is a map allowed to contain <String,
> String> or <String, Map> ?
The touchpoint data currently only handles String based "instructions.
For instructions that match a phase name we parse out actions using "InstructionParser".
Touchpoint data is open-ended though and for the most part it's up to the touchpoint to determine what is valid.
In 3.5 it might be reasonable to figure out what sorts of extenstions make sense to allow us to implement good tooling.
> - Is there some parameter substitution available? Thinks like $tmp,
> $home, $installdir etc?
There is a limited substitution available for parameters the touchpoint and phases injects into the parameter map.
I can add some concrete docs here but the actual parsing takes place in "ParameterizedProvisioningAction"
> - Do you think the touchpoint type/data construct will change
> significantly in 3.5?
The IU format will probably be the same or possibly tweaked in a backwards compatible way.
As far as code goes in 3.5 I think that in the process of making the touchpoint infrastructure API ready the contribution model will become more consistent and subsequently better for tooling.
>
> Henrik Lindberg
> henrik.lindberg@xxxxxxxxxxxxxx
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev