eclipse-ocl / org.eclipse.ocl

Eclipse Public License 2.0
0 stars 0 forks source link

OCLinEcore Editor discards Ecore model changes #1174

Closed eclipse-ocl-bot closed 3 hours ago

eclipse-ocl-bot commented 3 hours ago

| --- | --- | | Bugzilla Link | 415570 | | Status | CLOSED INVALID | | Importance | P3 normal | | Reported | Aug 21, 2013 08:42 EDT | | Modified | May 25, 2015 17:18 EDT | | Reporter | nicolas h |

Description

Created attachment 234608\ the two example projects

Hi,

The OCLinEcore editor discards modification I made on my Ecore model. The Ecore model is generated from a UML Metamodel. The way of doing this is described in the documentation available here: https://bugs.eclipse.org/bugs/attachment.cgi?id=55337

When both the Ecore model and the Generator Model were generated from de UML Metamodel, I opened the Ecore model with the OCLinEcore Editor and I tried to add custom validation message by suffixing the invariant name with the message between brackets. I can save the modification, but it seems not persisted, as I can see if I close and re-open the Ecore model.

The attachment contains two projects.

The 'OCLinEcoreExample' project contains:

The second project contains:

In both case, the metamodel is simple: an Hotel contains an undetermined number of rooms (each room has a room's number). Nonetheless an Hotel can't contain the room 1408 (the Devil's room).

The constraint is written in OCL:\ self.room->select(r : Room | r.number = 1408)->isEmpty()

In both case, the constraint is well valuated, but I can modify the Ecore model with the OCLinEcore Editor only for the Ecore model located in the first project. Changes made in this Editor for the Ecore model generated from UML are discarded.

OCL version is the 3.3.0.

Regards,

Nicolas

:compression: OCLinEcore.zip

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on Aug 22, 2013 12:19

The OCLinEcore editor did not discard any valid content.

In the UML case, the UML Constraint is represented in Ecore as an EOperation for which there is no message support, so addition of a body$message detail was a waste of time and the OCLinEcore editor has no obligation to persist garbage in OCL EAnnotations.

In the direct Ecore case, the constraint is represented as a constraint EAnnotation for which the body$message detail is useful.


This once again demonstraes that elaborating OCL expressions outside OCL runs into a myriad of tooling difficulties. THe proposal to elaborate within OCL by returning a Tuple of values should bypass supporting tools.

eclipse-ocl-bot commented 3 hours ago

By nicolas h on Aug 23, 2013 02:16

Hi Ed,

I understand, thanks for the information.

Sorry for wasting your time,

I'm waiting for the Tuple solution you proposed :)

Regards,

eclipse-ocl-bot commented 3 hours ago

By Ed Willink on May 25, 2015 17:18

CLOSED after more than a year in the RESOLVED state.