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?