Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-bpmn2.dev] BPMN2 for older Eclipse versions

Thanks Henning,

I agree. I btw have no objections to put OCL constraints into the metamodel itself. For our proprietary metamodel we do the same.

 

Regards,

 Reiner.

 

From: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] On Behalf Of Henning Heitkötter
Sent: Donnerstag, 9. September 2010 18:01
To: BPMN2 Developers Mailing List
Subject: Re: [mdt-bpmn2.dev] BPMN2 for older Eclipse versions

 

Hi Reiner,

(Note: I had written part of this mail prior to Antoine's mail yesterday. It's not that relevant if we can postpone the valdation implementation. I'm sending it nevertheless so it's not forgotten.)

I agree with you that having multiple branches at this stage would be too much work, as the code will be evolving fast.

We could do the following: while the core functionality isn't complete, we target EMF 2.4.
At the same time however, we can integrate the constraints into the ecore file as needed by the validation delegates concept, if we want to do so. This won't have a user-visible effect on the generated code as long as we have runtime version set to 2.4. All it takes to enable the validation is switching this value to 2.6.

This would, however, mean that we plan to switch or at least create a separate branch some time. Otherwise the effort would be wasted (as long as we don't implement a custom solution).

BTW: I opened a bug against EMF concerning the wrong reference to validate_EveryBidirectionalReferenceIsPaired generated even if runtime version is set to 2.4: https://bugs.eclipse.org/bugs/show_bug.cgi?id=324863

Regards,
Henning

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

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.

 

From: mdt-bpmn2.dev-bounces@xxxxxxxxxxx [mailto:mdt-bpmn2.dev-bounces@xxxxxxxxxxx] On Behalf Of Antoine Toulme
Sent: Montag, 30. August 2010 17:38


To: BPMN2 Developers Mailing List

Subject: Re: [mdt-bpmn2.dev] BPMN2 for older Eclipse versions

 

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?

 

Thanks,

   Reiner.

 

_____________________________________________
From: Hille-Doering, Reiner
Sent: Montag, 30. August 2010 16:18


To: 'BPMN2 Developers Mailing List'

Subject: RE: BPMN2 for older Eclipse versions

 

 

Some more detail:

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

 

 

Hi all,

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?

 

Thanks,

Reiner.

 

 

 


_______________________________________________
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

 


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

 

Back to the top