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

PS: The error originally is emitted by ECoreValidator. validateEReference_ConsistentOpposite(). You also see it if you right-click in the ECore editor and choose “Validate”.

 

Von: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im Auftrag von Hille-Doering, Reiner
Gesendet: Montag, 23. August 2010 16:51
An: BPMN2 Developers Mailing List
Betreff: AW: [mdt-bpmn2.dev] Multi-file support

 

I have changed „transient“ together with resolveProxies, because else opening .genmodel shows me the nasty error  “The opposite of a transient reference

> must transient if it is proxy resolving”.

Unfortunately you are right: setting “transient” to true on the storage side has the effect that the reference is not serialized at all.

I didn’t find a lot of information about the flags and there conditions:

General meaning of the flags:

http://publib.boulder.ibm.com/infocenter/rtnlhelp/v6r0m0/index.jsp?topic=/org.eclipse.emf.doc/references/overview/EMF.html

Discussion about the “transient resolve proxies issue”:

http://dev.eclipse.org/newslists/news.eclipse.tools.emf/msg23116.html

I really don’t know what to do  here, except removing the non-storage end of the association or some more in-depth tricks in our resource implementation.

Any ideas?

 

Reiner.

 

 

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

 

No problem, I think we didn't duplicate any work ;-)
I will update the Excel sheet later.

I noticed that you changed the transient property on some of the references to true (e.g. BoundaryEvent.attachedToRef). Was this done on purpose? If I'm not mistaken, transient features won't be serialized, but these should be?

Regards, Henning.

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

Hi Henning,

wow, this is funny. You sent you mail almost exactly in the moment when I wrote my other one J .  Thanks to the work again – I agree with your proposals.

As I have already applied some of the issues in your Excel, but not completely, I would ask you to update it ones more to differentiate the fixed on non-fixed ones. And after you have done your feature in the templates, we continue in a coordinated manner ;-)

 

Regards,

  Reiner.

 

 

Von: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im Auftrag von Henning Heitkötter
Gesendet: Montag, 23. August 2010 13:44


An: BPMN2 Developers Mailing List
Betreff: Re: [mdt-bpmn2.dev] Multi-file support

 

Hi Reiner,

that's good news!

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

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.

See the attached document.

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.

We could add another details entry to the ExtendedMetadata of these classes (e.g. abstract -> true). Additionally, I suggest to change the template FactoryClass.javajet to the effect that the create method for originally abstract classes does not appear in the interface Bpmn2Factory and is not public in Bpmn2FactoryImpl. Thus it can be created during deserialization (which calls EFactory.create(EClass)) but is somewhat hidden to users.
ItemProvider.javajet will likely have to be adapted as well (@ collectNewChildDescriptors).
If you're OK with that, I'd try to tweak the templates accordingly.

Regards,
Henning

 


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

 


Back to the top