Hi Henning,
I understand the point. The problem for me is that SAP
absolutely requires an BPMN 2.0 Ecore for Eclipse 3.4 and 3.5. If MDT BPMN2
decides to stick on Helios and higher, we need a kind of branching off the
current status. As long as we work at the core functionality (e.g.
serialization/deserialization, metamodel bugs and so forth, having multiple
branches is not really good.
Any ideas?
Regards,
Reiner.
From: mdt-bpmn2.dev-bounces@xxxxxxxxxxx
[mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] On Behalf Of Henning
Heitkötter
Sent: Mittwoch, 8. September 2010 10:20
To: BPMN2 Developers Mailing List
Subject: Re: [mdt-bpmn2.dev] BPMN2 for older Eclipse versions
Hi all,
I had hoped that we could leverage the new validation delegates concept from
EMF 2.6 to implement constraints from the specification in OCL (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=319254).
I do believe that this offers a really elegant solution, as constraints would
be defined directly in the ecore file and no manual modification of generated
code would be necessary. Thus, everything would be defined in one place in a
concise form.
But this would, of course, require EMF 2.6/Helios. Validation can be
implemented with previous versions of EMF, but in a less straightforward manner
(EMF generates validating methods that have to be modified to implement the
constraints in Java). Alternatively, we could reimplement part of the new EMF functionality
(see for example http://www.eclipse.org/articles/article.php?file=Article-EMF-Codegen-with-OCL/index.html
from 2007), but that seems like a lot of work when a solution is already
available.
So, I think that this would qualify as an feature important enough to break
compatibility with previous versions. What do you think?
Thanks,
Henning
2010/8/30 Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx>
I assume until we try to
implement an important feature leveraging 3.6 (or later) that we cannot
implement (easily) without breaking 3.5 compatibility.
Looks
ok to me. How long will we support 3.5 then ?
On
Mon, Aug 30, 2010 at 08:34, Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx>
wrote:
Finally I found a quite elegant
solution: Change “Runtime Version” property in .genmodel file to “2.4” creates
(almost) completely that code that is compilable with Eclipse 3.4 and still is
fully compatible to everything we have implemented so far (diffs show really
only the changes mentioned below).
What do you think? Should I submit?
_____________________________________________
From: Hille-Doering, Reiner
Sent: Montag, 30. August 2010 16:18
To: 'BPMN2 Developers Mailing List'
Subject: RE:
BPMN2 for older Eclipse versions
With the current codebase excluding
tests, an Eclipse 3.5 shows 26 compilation errors. 22 of them are of kind
“The method shouldComposeCreationImage() must override or implement a supertype
method”, because EMF 2.6’s ItemProviderAdapter has the new method
“shouldComposeCreationImage”, which older version don’t have.
The older EMF always tried to find a
create image in "full/ctool16” directory. Only in case of missing file it
created a compound image. EMF 2.6 reduces the number of thrown and caught
exceptions with this method.
We theoretically could remove it from
the template and would simply go back to the former behavior.
The other 4 errors are caused from new
validation methods called from DiValidator and DcValidator. Only those two
packages do have validors, because of some OCL content that we inherit from DD.
_____________________________________________
From: Hille-Doering, Reiner
Sent: Montag, 30. August 2010 13:49
To: 'BPMN2 Developers Mailing List'
Subject: BPMN2 for older Eclipse versions
some (potential) BPMN2 project users need the BPMN 2.0
metamodel not only for Helios, but also for former Eclipse versions.
So far this was not a problem, as the code was almost
compatible – only in two files in the model that used OCL constraints (from the
DI part), some lines needed to be commented out.
With Hennings latest changes – which of cause do make
sense – we use the newest EMF code generation templates, and thus the code used
e.g. on Eclipse 3.5 causes tons of compilation errors.
Even regeneration with old Eclipse versions does not
create compilable code, as we have checked in some modified copies of the
Helios templates.
Any ideas how we could provide a backward-compatible
version of our metamodel?
_______________________________________________
mdt-bpmn2.dev mailing list
mdt-bpmn2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev
_______________________________________________
mdt-bpmn2.dev mailing list
mdt-bpmn2.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-bpmn2.dev
|