| Invariant both passes and fails ?? [message #1860416] |
Thu, 03 August 2023 17:30  |
 Steve Hickman
Messages: 56
Registered: August 2017 |
Member |
|
|
If I understand correctly what I'm seeing (see attached screenshots), the same invariant is both succeeding and failing.
It appears that the invariant succeeds/passes in those cases where it is not prefixed by the OCL filename where it is defined and fails in those cases where it is prefixed by the OCL filename.
In the ValidityView screenshot, you can see both the successes and failures. In the other two screenshots, you can the success and failure details.
I've also attached the OCL files where these invariants are defined.
What is going on? Is there something I'm doing wrong here? These invariants should pass. What is causing the failures? Is it possible that the problem is that an invariant in one file is referencing a def in a different file? I would think that the `includes` would take care of that.
I should also note: This fail/success behavior does not occur for all invariants. I have some that pass both with the filename prepended and without. (That does raise the question: 'Why are they displayed twice - once with the filename prepended and once without?')
Background:
I'm using OCL-> Load Document to load an OCL file. That OCL file includes others, which also include others, etc. The original OCL file is in one project / package based on one XText grammar/metamodel (named Omodel). Some of the included OCL files are based on other XText grammars/metamodels that are 'base' grammars/metamodels to Omodel (Omodel builds on Privacy which builds on FACE which builds on UDDL).
[Updated on: Thu, 03 August 2023 17:43] Report message to a moderator |
|
|
|
|
| Re: Invariant both passes and fails ?? [message #1860436 is a reply to message #1860420] |
Fri, 04 August 2023 19:29  |
Steve Hickman
Messages: 56
Registered: August 2017 |
Member |
|
|
Your comment was the key. While attempting to reduce the model, I realized the following:
1) I have OCL based on 4 different XText / Ecore metamodels. OCL that depends on a particular metamodel is in a directory in the project that also contains that metamodel.
2) I had been using a mix of relative path names when one OCL file includes another within the same plugin, `platform:/resource/...` URLs when including a file from a different plugin, and `http` URLs for the ecore metamodels themselves.
3) I was loading an OCL file at the top of that 4 metamodel stack which transitively included OCL files from each of the 3 other layers. I used OCL -> Load Document -> Browse File System to load all the OCL files into an second Eclipse to test the XText languages.
4) I had not included the projects containing the OCL in the workspace with the models I'm loading the OCL against (although all the plugins generated by these projects are part of the 2nd Eclipse runtime)
The net result of all of this is that when the selected document was loaded, Eclipse couldn't figure out where the included OCL files were in some cases. So, naturally, those didn't get loaded. And that broke things in the ones that did.
Once I changed all the includes to use 'platform:/resource' and included the projects that contain both the Ecore metamodels and the OCL in the 2nd Eclipse' runtime workspace (so that they were resources known to that 2nd Eclipse), the problem disappeared.
Net result: I don't know that you need to change anything. Maybe this note will be sufficient to help others past problems like this.
[Updated on: Fri, 04 August 2023 19:32] Report message to a moderator |
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04564 seconds
] 
Search
Help
Register
Login
Home
