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
Hi Antoine.

So the RTF will provide the validation constraints, presumably in OCL? Which we can then integrate into our project - relieving us from the need to skim through the specification and derive constraints on our own :)? Do I understand you correctly there?
In that case you are of course right that we should concentrate on other areas first.

Nevertheless some comments regarding the choice of technology for validation (possibly for future reference) - caveat: I've never worked with the EMF Validation Framework ;-) Perhaps I'll able to convince you of the validation delegates concept - or I can understand your concerns regarding it better.

If we are supplied with ready-to-use OCL constraints, we should use these directly.
I'm not sure if you used OCL in the solution for the BPMN modeler you mentioned? (I had a quick look at http://git.eclipse.org/c/bpmnmodeler/tree/org.eclipse.stp.bpmn.validation, but there custom java code seems to be used?)
With validation delegates, using OCL is straightforward - all we have to do is augment the ecore file, no additional code is needed. This has the additional benefit that the complete metamodel, that is the abstract syntax and the static semantics of BPMN, is defined at one place. (We are of course still free to extract the constraints when for example a list of them is needed.)
I believe that with the delegates concept we will need to invest less effort to implement the framework for validation (nearly zero) as well as the actual constraints.

I'm sure that the dependence on validation-specific elements/plugins (e.g. OCL) can be made optional with the delegates concept as well (e.g. by overriding the validate-method of EObjectValidator responsible for evaluating constraints). This way our plugin would still be usable without validataion.
(Note that this does not deal with the incompatibilities between 2.4 and 2.6 - see my next mail for a proposal how to deal with 2.4 compliance.)

Regards,
Henning

2010/9/8 Antoine Toulme <antoine@xxxxxxxxxxxxxxx>
Caveat: I never played with 2.6 OCL support.

I discussed with Denis Gagne during the last OMG meeting in Minneapolis and he believed he would be working with OCL to express the validation constraints. That work should take place this fall and I am looking forward to it.

I am not very excited by the possibility to do OCL directly in the ecore. 
I coded before a validation system for the BPMN modeler where we had validation constraints specified in a separate plugin, and it worked well (we were still using the validation framework from EMF, but each validation constraint was defined in the plugin.xml completely).
In particular, I had appreciated the accent on the descriptive aspect of the constraints. I also liked that you could drop the validation framework and run with just the model if needed.

I believe we can use that for the time being. I don't think we have to rush a decision, as the work on OCL didn't start on the RTF.



On Wed, Sep 8, 2010 at 02:30, Hille-Doering, Reiner <reiner.hille-doering@xxxxxxx> wrote:

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



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


Back to the top