[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] P2 metadata authoring - status/questions

Thanks Simon,
The code is in the Buckminster SVN - I have not packaged it up as a feature, and I reused some Buckminster bundles to make faster progress. Expect to work on it a couple of days more before I have it packaged for easier consumption - right now there are several buckminster bundles needed to make it run (my plan is to remove the dependencies as I am mostly using utility functions).  The code can be found at: svn://dev.eclipse.org/svnroot/tools/org.eclipse.buckminster, in the project org.eclipse.equinox.p2.authoring.
What is working now:
- creating a new IU file (extension .iu) via a new file wizard
- open, save, save as
- edit of general things (name, namespace, singleton, etc)
- edit of provided capabilities
- edit of required capabilities (no lookup in repositories yet, just manual editing)
- editing of artifact keys (no lookup in an artifact repository yet, just manual editing)
- editing of information: description, license and copyright
- validation of urls, structured names etc. "as you type" with error markers next to fields, and popup list with popup menu/links to fields in header
- undo/redo of all edits that also switches between the pages/tabs in the editor as edits are undone/redone

Some follow up on your answers

> - 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.

In that case, shouldn't the Version be a Version Range? 

 
> Now some more questions:
> - Do you think it makes sense to be able to edit all of these [some 30 different touchpoint data], 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.

ok - I will probably do this via some sort of meta data generated form details.

> - 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.

ok, will do that - that will be the basis for the meta data that drives the forms.

> - 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.

When I looked in code, it indicates that some operations that require more than one parameter have them in a map. As an example, "unzip" takes two parameters; PARM_SOURCE, and PARM_TARGET, which I assumed is encoded as <"unzip", Map (<PARM_SOURCE, "xxx"><PARM_TARGET, "yyy">) >. Is this assumption correct?

> - 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"

Will look at ParameterizedProvisioningAction and include what I find in the documentation I will prepare.

> - 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.

ok. As I want to do something right now to drive forms editing of the parameters, and will need some sort of meta data format, are there any preferences? Something that is used elsewhere that I should look at? My idea is to have an extension point that allows a provider to plugin editing support for a particular version of a touchpoint (to make it posible to edit IUs that use touchpoints that are not available in the authoring environment other than as meta data descriptions). 

Say, something like an ITouchpointDescriptor interface that has methods to:
- get the values for the touchpoint type (id, version, etc), 
- get a collection of ITouchpointInstructionDescriptor that describes each instruction/action (label, icon, name/validator/label per parameter, etc.)
- get a label provider for ITouchpointDescriptor
- etc...

Should I just go ahead and implement something as a proposal?

Henrik Lindberg