Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [mdt-bpmn2.dev] Multi-file support

Hi Henning,

thanks for the fix in deresolve and also the typos. This is of cause correct. I just didn’t test the case yesterday, but before we had the case handled of cause.

About the resolveProxies thing:

I have spend some time thinking about it. Indeed I started with the approach you outlined: The merge tool sets resolveProxy to true if the XSD reference is a QName. Then you detected the issue in Bugzilla 316591.

Then I started to think that we can’t use resolveProxies, as we don’t have type information in our files.

However, cross-file references without proxies will simply not work.

But I have the solution now:

My mistake was that I did believe that proxies must have the same type as the final object.  But this is not needed. The problem in BZ 316591 was simply that the target type of the reference is abstract, so that EMF could not create a proxy. Solution is simple:

1.       Clean up the model according to you Excel (thanks for the work J ) to use resolveProxy=true for references that can span files.

2.       For all those references, check if the target type is abstract. If yes, remove the abstract flag. If you like you could extend your Excel to mark those cases.

3.       It would be good to store somewhere that the type was originally abstract to avoid users to accidently create instances of it (e.g. in the editor). But EMF must be able to create proxies of this type for sure. We could e.g. change use the genModel “image” flag for keeping the information of former abstract classes.

4.       The rest should be done by OnlyContainmentTypeInfo etc.

 

Best regards,

 Reiner.

 

 

Von: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im Auftrag von Henning Heitkötter
Gesendet: Freitag, 20. August 2010 15:20
An: BPMN2 Developers Mailing List
Betreff: Re: [mdt-bpmn2.dev] Multi-file support

 

Hi Reiner,

thanks a lot, this looks very good.
I've just committed a small fix for QNameURIHandler.deresolve to handle local references without writing a '#', so that it is a valid QName. It would be nice if you could check that the change is OK (it should be, but as the author you probably understand the possible implications better).

Regarding the general approach:
As far as I see, you rely on resolveProxies to distinguish between normal (IDREF in XSD) and cross-file references (QName in XSD). [deresolve is called by XmlHelper.getHREF, but not XmlHelper.getIDREF. HREF is called when resolveProxies=true, IDREF if false.] Note that there are some inconsistencies between the XSD and our model, as described in the attached spreadsheet. These will have to be fixed, but:
If we rely on resovleProxies, we need to find a solution for the problem described in comments 17-23 of bug 316591 (re OnlyContainmentTypeInfo - https://bugs.eclipse.org/bugs/show_bug.cgi?id=316591#c17). For example, at the moment StartEvent.eventDefinitionsRefs causes the exception mentioned in the bug if set (as would EndEvent.eventDefinitionsRefs, if resolveProxies was still false for ThrowEvent).

Thanks,
Henning

2010/8/19 Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx>

Hi BPMN friends,

I have just committed the first chunk to support multiple files for one BPMN model.

The code is relatively short, but kind of tricky, as I need to hook into multiple places of XmlResourceImpl and its helper classes.

So I would ask you to check and test the code and correct if you have a better solution.

Here is how you can use the feature:

  1. Create a BPMN file with the Wizard, e.g. called “inner.bpmn2”. Give it a target namespace (property of Definitions, e.g. “org.omg.bpmn2.sample.inner”. Create a Process, e.g. called “Process 1” there and save.
  2. Create a second BPMN file, e.g. called “outer.bpmn2” in the same directory. Give it also a target namespace, e.g. “org.omg.bpmn2.sample.outer”. Add an Imports object (as child of Definitions).  Set following properties:

·         ImportType: http://www.omg.org/spec/BPMN/20100524/MODEL

·         Location: inner.bpmn2

·         Namespace: org.omg.bpmn2.sample.inner

  1. Add a collaboration to outer.bpmn2 with a participant.
  2. Right-click on the background of the editor and choose “Load resource…”. Locate “inner.bpmn2” and choose Ok. You will see “inner.bpmn2” in the editor tree.
  3. In the participant’s ProcessRef dropdown you will now see “Process 1” from “inner.bpmn2”. Select it and save the editor. You should find correct QName references in outer.bpmn2 pointing to inner.bpmn.
  4. If you close the editor and reopen, you can nicely see how EMF demand-loads “inner.bpmn2” in the moment when you navigate to the participant.

 

I didn’t do in depth testing, e.g. with references that have an abstract type, so I’m sure there will be issues. Please let me know. You can also see interesting effects with the  “Buyer Selller” example from the Spec that imports an XSD and a WSDL. Currently I don’t disable this, as this is quite nice in EMF.

 

Reiner.

 

 


_______________________________________________
mdt-bpmn2.dev mailing list
mdt-bpmn2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev

 

Back to the top