Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[mdt-ocl.dev] Re: OCL Encoding problem

Ed,

Details on the new support for adding constraints to Ecore models (via "validation delegates") can be found at http://wiki.eclipse.org/EMF/New_and_Noteworthy/Helios#Support_for_Validation_Delegates. On that same page, you'll also find details on feature setting delegates and operation invocation delegates. I'll be blogging about all of these in the near future.

Cheers,

Kenn

On Sun, Dec 6, 2009 at 5:12 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi Bernd

There have been opportunities to track what we are up to.

On 20th June, I started an mdt-ocl.dev thread to discuss publicising changes: http://dev.eclipse.org/mhonarc/lists/mdt-ocl.dev/msg00080.html as precursor to attract the attention oif all MDT OCL users by posting http://www.eclipse.org/forums/index.php?t=msg&th=22278&start=0&S=0ca06c1e664b7ac6689dd05713c85cfe to the MDT OCL newgroup.

We maintain the wiki page http://wiki.eclipse.org/index.php?title=MDT/OCL_3.0.0_API_Changes to provide an overview of changes and progress. A more detailed overview is at http://wiki.eclipse.org/MDT/OCL/Dev/Areas.

In https://bugs.eclipse.org/bugs/show_bug.cgi?id=192506 to which Anthony added you as a CC, I suggested migrating the OCLv and OCLq code to MDT/OCL. You now seem to be making a similar suggestion. However, I think this may be overtaken by events.

Today there are a couple of not entirely satisfactory ways of adding constraints to EMF models. Kenn has nearly finished developing a new (hopefully much better) integration, so the existing approaches want to give way to Kenn's new way. Perhaps Kenn can give us all some guidance.

On validation more generally: MDT/OCL currently does too much semantic checking during the analysis phase that creates the AST, rather than the subsequent validation phase. This means that semantic errors in third party ASTs are not diagnosed. The aim is to move as many checks from the analysis to the validation phase. In principle these should all be defined in OCL and match text in the OMG specification. Until we have efficient Java synthesis from OCL, I'm inclined to continue with hand coded validation, though it would be nice to be able to do back-to-back JUnit testing to demonstrate that the hand-coded validator was the same as the OCL-defined validator. If these activities align with your interests, we would be delighted to have some help.

The patch looks to just eliminate very old deprecated functionality, so it looks sensible. Your comments have a typo which makes it difficult to know quite what you want.

    Regards

       Ed Willink


Kolb, Bernd wrote:

All,

 

Validation has a patch in this bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=294549 to work with the new OCL 3 stuff. But before committing it to HEAD we’d like somebody else to validate that as this is breaking API. I agree with Ed that is a bit unfortunate that the upstream projects get to know these changes that late.

 

A more general concern I have with OCL and validation are the dependencies. From my point of view the OCL integration with validation should be done in the validation project. What do you think? We would be willing to continue maintenance and further development but if possible as part of the OCL project.

 

Bernd



Back to the top