Community
Participate
Working Groups
Hi, the keyword change from derive to derivation must be forgotten in org.eclipse.ocl.ecore.delegate.SettingBehavior line 108 String expr = details.get(DERIVATION_CONSTRAINT_KEY);. DERIVATION_CONSTRAINT_KEY holds derivation which is incompatible with the old implementation. This causes an exception wich is catched and not shown to the user. Ralph
Ralph, "derivation" was in there since what became commit 55bda1bd267269289d6cfc3e7a82d9df6cd987a8 after migrating from CVS to GIT. The commit dates back one year and eleven months. I'm not sure I understand where you think the implementation did support "derive" instead of "derivation" in the past. Could you please be more specific so we can take a closer look? Thanks and best, -- Axel
The SettingBehavior code has always used DERIVATION_CONSTRAINT_KEY which has always been "derivation". I suspect that you're getting confused with "derive" which is the stereotype spelling.
Hi, I thought this because I get code generated for derive and derivation.. Should there be code generated when using derive as key in the annotation? Ralph
Your comments make no sense to me. I suggest you try to describe what you are doing, what you observe and how that differs from what you expect to observe, and since you are reporting a regression, also report what version you are currently using and what different behaviour you observed with what other version.
Created attachment 209303 [details] Example Project Hi, here is the project what I use. I did set the key of the annotation of BookSubtype.resultOfOpOclOfSubBook to derive. It generates code for the getter, which I would expect that it does not as the annotation is invalid. Now start a workbench with this three plugins-deployed. Create a tutorial 3 model. Use Library as the root element. Create an instance of BookSubtype. You will see that the derived value is not filled in the properties view. This comes due to the exception that occurs. Hope that helps further. Ralph
You make life very hard for yourself by using the Ecore editor to edit OCL. You get absolutely no checking and there are many opportunities for errors. Would you edit Java with Notepad? If you use the OCLinEcore editor you will get something much more useful and all the delegate EAnnotation infrastructure is autogenerated. Load tutorial3.ecore with the OCLinEcore editor and you will see no OCL for resultOfOpOclOfSubBook because "derive" is ignored. Unfortunately the encompassing delegate still triggers generation of the delegate. Please submit a bug against EMF genmodel for the lack of genmodel diagnostics; we need an ability to specify genmodel validation rules. Change the key to "derivation" and it will work much better, and the OCLinEcore editor will show the text and syntax check it for you.
Hi, I already thought about validating the genmodel. Because I noticed that there are problems which you do not get pointed to when using Compliance Level 1.4 which is the default. The reason for not using OCLInEcore is that it makes my life harder as I always get problems when saving my changes. It very often happened to my that it brings up a message that says changes are not saved for some reason or it breaks my meta model. Basically this is why I do not use that editor. I will open a bug in genmodel validation. Ralph
I've fixed on OCLinEcore save bug for source-less EAnnotations; arguably an illegal model. Other than that raise a bugzilla on the real problem. Even if you have a save problem, you can still use OCLinEcore to view your model.
CLOSED after a year in the RESOLVED state.
