| AW: [mdt-bpmn2.dev] Multi-file support |
|
I have rolled back most of my changes from yesterday, as I think
they fall in category 1. I kept however the EventDefinition non-abstract and
the resolveProxies=true for ThrowEvents. This case is not critical, as the association
is not bidirectional. Von: Hille-Doering,
Reiner Hi Henning, yesterday I had the chance to chat with Ed Merks about the
problem (good to have a colleague here that knows him well :-) . The fact is simply that EMF requires for bidirectional
associations spanning multiple files to have storage on both sides. I see that following options: 1.
Let the bidirectional
association NOT span multiple files. E.g. in case of BoundaryEvent.attachToRef
we could go back and have resolveProxies=false. I think this is Ok, as BPMN
spec intended only RootElements for be accessible by QName. I would follow the
same argumentation for SequenceFlow stuff and similar. 2.
Remove the opposite reference
that has no storage (meaning that the corresponding feature does not exist in
the schema, and in Metamode we have today transient=true). This would be Ok in
some cases, but often it causes a not-so-nice API and also a derivation from
the CMOF original. It could also have a negative effect on our XMI
compatibility. 3.
Set both references to
“transient=false”, meaning that we have storage on both sides. I don’t think
that this is an option, as we would violate the BPMN 2.0 scheme. 4.
Replace the non-storage end
by a custom-developed method, that e.g. uses the CrossReferencer to mimic a
backward navigation. This is the option that Christian Damus proposes in the
post below. 5.
Implement a semi-consistent
bidirectional association: In the moment when the proxy is resolved on storage
side, update also the object on other side. Solutions 4. and 5. require custom code on the feature getters
and setters. If we go for it, we could use the standard “generated NOT”
approach, use a customer generation template, or leverage the new “feature
delegate” concept from Helios. I would suggest that we consider options 1 and 2 in the excel
(and code) where it makes sense, and implement either 4 or 5 for the remaining
cases. Regards, Reiner. Von:
mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] Im
Auftrag von Hille-Doering, Reiner 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: 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 No problem, I think we didn't
duplicate any work ;-) 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
Hi
Reiner, 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.
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.
|