Hi Antoine,
your change is ok, maybe a little slower than before.
Anyway: What kind of files do you read that don’t have a Definitions
element but still need to use the targetNamespace field during load? And if
your files don’t contain a Definitions element, how does your code work without
NPE?
Regards,
Reiner.
From: mdt-bpmn2.dev-bounces@xxxxxxxxxxx
[mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] On Behalf Of Antoine Toulme
Sent: Freitag, 27. August 2010 00:18
To: BPMN2 Developers Mailing List
Subject: Re: [mdt-bpmn2.dev] Multi-file support
I changed a few things in the BpmnXmlHelper as it was
failing for me.
I construct bpmn documents out of nothing and there is no
Definitions object when we load the resource, so the lifecycle of the xml helper
was not working for me, leading to NPEs later on.
I changed the code specifically to get the Definitions
object lazily ; this way the Definitions object may be swapped out.
There is no good support for the case where there is no
Definitions object defined at all in the document.
Please review my commit and let me know.
Antoine
On Wed, Aug 25, 2010 at 04:17, Henning Heitkötter <hheitkoetter@xxxxxxxxxxxxxx>
wrote:
Hi Reiner,
I've added the inconsistencies regarding QNames that we've identified to bug
323240 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=323240).
However, I'm still unsure about ConversationLink. IMO, cross-file references do
not have to target RootElements: see for example MessageFlow, which will likely
(and IMO rightly) also be used to connect nodes from different files (one file
per process), whereas these nodes are not root elements.
If the conversation link connects Participant and ConversationNode, I agree
with your statement in the spreadsheet that they will be in the same
collaboration container and, thus, in the same file. However, if a
ConversationNode is connected to a Task or Event (like in Figure 9.28 of the
spec), these will be contained in a process, which could be stored anywhere.
Therefore I believe that the references of ConversationLink belong to category
4 (or 2, if we decide so).
Regards,
Henning
2010/8/25 Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx>
Excellent! I have added some
comment to the GoogleDoc Table with the cases you mentioned in the last mail.
I've
pushed the changes concerning the hiding of originally abstract classes (@
Factory and ItemProvider). To the user, EventDefinition should now appear as if
abstract.
_______________________________________________
mdt-bpmn2.dev mailing list
mdt-bpmn2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev
|