RE: [equinox-dev] P2 touchpoint parsing/writing problem

["Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>]

Ciao Henrik :)
My comments from a pure p2-user perspective:
Instead of your way

<instruction key='install'>
	doSomething(target:some target value, source:some source value);
</instruction>
<instruction key='install'>
	doSomethingElse(source:some source value, target:some target
value);
</instruction> 

I'm using a different approach that works just fine:

<instruction key='install'>
	doSomething(target:some target value, source:some source
value);doSomethingElse(source:some source value, target:some target
value)
</instruction>


Just my 2c, this might help you work around the p2 bug...
Ciao, hh

From: equinox-dev-bounces@xxxxxxxxxxx
[mailto:equinox-dev-bounces@xxxxxxxxxxx] On Behalf Of Henrik Lindberg
Sent: 27 June 2008 03:40
To: Equinox development mailing list
Subject: [equinox-dev] P2 touchpoint parsing/writing problem

Hi,
I encountered a problem with reading and writing IU touchpoints.  The IU
supports multiple touchpoints - the getTouchpointData() method returns
an array of TouchpointData, and it is possible to add mulitple
touchpoint data. 

When writing the IU as XML however, all the touchpoint data gets merged.
When reading this back in again, the result is a map where instructions
are overwritten.

This is what touchpoint writer does:

protected void writeTouchpointData(TouchpointData[] touchpointData) {
if (touchpointData != null && touchpointData.length > 0) {
start(TOUCHPOINT_DATA_ELEMENT);
attribute(COLLECTION_SIZE_ATTRIBUTE, touchpointData.length);
for (int i = 0; i < touchpointData.length; i++) {
TouchpointData nextData = touchpointData[i];
Map instructions = nextData.getInstructions();
if (instructions.size() > 0) {
start(TOUCHPOINT_DATA_INSTRUCTIONS_ELEMENT);
attribute(COLLECTION_SIZE_ATTRIBUTE, instructions.size());
for (Iterator iter = instructions.entrySet().iterator();
iter.hasNext();) {
Map.Entry entry = (Map.Entry) iter.next();
start(TOUCHPOINT_DATA_INSTRUCTION_ELEMENT);
attribute(TOUCHPOINT_DATA_INSTRUCTION_KEY_ATTRIBUTE, entry.getKey());
cdata((String) entry.getValue(), true);
end(TOUCHPOINT_DATA_INSTRUCTION_ELEMENT);
}
}
}
end(TOUCHPOINT_DATA_ELEMENT);
}
}

For an IU with two touchpoints, with one install instruction each - the
output is:

   <touchpointData size='2'>
      <instructions size='1'>
        <instruction key='install'>
          doSomething(target:some target value, source:some source
value);
        </instruction>
        <instructions size='1'>
          <instruction key='install'>
            doSomethingElse(source:some source value, target:some target
value);
          </instruction>
        </instructions>
      </instructions>
    </touchpointData>

 


When the parser reads this back in  - it gets the hint that there are
two touchpoint data, but there is just one instructions element. The
parser seems to be able to handle multiple instructions elements. So I
think the writer is to blame, and that there should be an
end(TOUCHPOINT_DATA_INSTRUCTIONS_ELEMENT) after looping over the
instructions. Like this:




protected void writeTouchpointData(TouchpointData[] touchpointData) {
if (touchpointData != null && touchpointData.length > 0) {
start(TOUCHPOINT_DATA_ELEMENT);
attribute(COLLECTION_SIZE_ATTRIBUTE, touchpointData.length);
for (int i = 0; i < touchpointData.length; i++) {
TouchpointData nextData = touchpointData[i];
Map instructions = nextData.getInstructions();
if (instructions.size() > 0) {
start(TOUCHPOINT_DATA_INSTRUCTIONS_ELEMENT);
attribute(COLLECTION_SIZE_ATTRIBUTE, instructions.size());
for (Iterator iter = instructions.entrySet().iterator();
iter.hasNext();) {
Map.Entry entry = (Map.Entry) iter.next();
start(TOUCHPOINT_DATA_INSTRUCTION_ELEMENT);
attribute(TOUCHPOINT_DATA_INSTRUCTION_KEY_ATTRIBUTE, entry.getKey());
cdata((String) entry.getValue(), true);
end(TOUCHPOINT_DATA_INSTRUCTION_ELEMENT);
}
// ! ! ! ! ! ! ! ! ! 

// MISSING END OF INSTRUCTIONS

end(TOUCHPOINT_DATA_INSTRUCTIONS_ELEMENT);
}
}
end(TOUCHPOINT_DATA_ELEMENT);
}
}

This is from version 1.14 of MetadataWriter - which I think is the
latest - or is this something that has been fixed? 

Regards.



Henrik Lindberg
henrik.lindberg@xxxxxxxxxxxxxx