Eclipse 2024-03 DSL + OCL 6.20 - ValidityView not showing invariants #2332
Comments
|
By Steve Hickman on Mar 18, 2024 13:36 Per https://bugs.eclipse.org/bugs/show_bug.cgi?id=582722 I used the same Eclipse install described below to do the following:
When I did this, I got a Validity View that had content for both Model Elements and Model Constraints. I was able to right click -> Validate each Model Element without any runtime errors in the Console window. |
|
By Steve Hickman on Mar 18, 2024 13:38 Note that the test steps using the Complete OCL Tutorial were not identical to those described in the other bug report because the OCL menu did not appear in my context menu. |
|
By Ed Willink on Mar 25, 2024 13:15 (In reply to Steve Hickman from comment #0)
3.7 is vague. 3.7.0 would be 8 years out of date. I presume you selected 3.7.15
Does the error log have anything interesting?
oops. Sorry. I just missed the 7 day invitation timeout. Please re-invite. Your repro involves a large number of steps. Presumably once you have created the project, you can close and reopen Eclipse and demonstrate the inadequate VV contents with just a couple of actions. Please attach a ZIP of this project or add to your GitHub so that I can follow more accurately and easily. |
|
By Ed Willink on Mar 25, 2024 13:31 (In reply to Ed Willink from comment #3)
Once I use git rather than https I seem to be able to clone - no problem(In reply to Steve Hickman from comment #0)
You seem to think I know something about UDDL. I don't. There is no way I can follow this repro. (I don't have a Mac but I doubt that will be relevant.) For a DSL I expect to find a *.xtext file. I see none. |
|
By Steve Hickman on Mar 25, 2024 14:20 Created attachment 289328 The grammar from the default XText project |
|
By Steve Hickman on Mar 25, 2024 14:21 Created attachment 289329 A simple OCL file with 1 invariant |
|
By Steve Hickman on Mar 25, 2024 14:25 Created attachment 289330 This is the full stack trace that appeared. :notepad_spiral: stacktrace.txt |
|
By Steve Hickman on Mar 25, 2024 14:27 My apologies. Here's a simpler repro: I uninstalled Acceleo so the Eclipse had only the following in this order:
Then I created the default XText project: I then add this org.xtext.example.mydsl/src/org/xtext/example/mydsl/test.ocl file: ----- package myDsl context Greeting
|
|
By Ed Willink on Mar 25, 2024 14:35 (In reply to Steve Hickman from comment #8)
`
The stack trace has nothing to do with OCL, indeed I see no EMF project. The NPE is fairly clear LSP bug that probably occurs when you provoke lazy creation of a menu that involves the defective LSP code. Probably a red herring. (If a model was involved, I might observe that a failure to specify an nsURI for an Ecore EPackage or a uri for a UML model is a favourite gotcha for an under-developed model.) |
|
By Steve Hickman on Mar 25, 2024 15:19 Created attachment 289331 |
|
By Steve Hickman on Mar 25, 2024 15:22 Created |
|
By Steve Hickman on Mar 25, 2024 15:24 Comment on Ignore this. It was accidentally empty |
|
By Steve Hickman on Mar 25, 2024 15:25 Created attachment 289333 Corrected :compression: mytest.zip |
|
By Steve Hickman on Mar 25, 2024 15:34 Created attachment 289334 Per https://eclipse.dev/Xtext/documentation/102_domainmodelwalkthrough.html, this project was created using File -> New -> Project -> Java Project. :compression: myjtest.zip |
|
By Ed Willink on Mar 25, 2024 16:33 I have no idea what the relevance of what you are attaching is. I see no constraints / *.ocl. I see a *.mydsl but no grammar / *.xtext. Is the problem that you are trying to report perhaps that the nominally implicit text2model performed by Xtext is not performed in a way that allows the text to contribute to the VV? If so, you should provide a ZIP of the fully-generated DSL project so that I can instalkl it in my workspace. And a ZIP of a 'test' project that I can install in a nested Eclipse, the open a test file and fail to see VV contents. The above can be demonstrated using Xtext as the DSL by opening org.eclipse.ocl.examples.project.completeocltutorial/model/XtextTestFile.xtext in the Xtext editpr, then OCL-loading org.eclipse.ocl.examples.project.completeocltutorial/model/ExtraXtextValidation.ocl and then the VV shows contents. |
|
By Steve Hickman on Mar 26, 2024 13:42 Created attachment 289336 This archive contains the fully generated DSL from the default XText project. This was created using the following steps:
This zip file also contains :compression: Archive.zip |
|
By Steve Hickman on Mar 26, 2024 13:56 The attachments labelled 'The entire project' and 'A Java project (converted to XText) with the same model' both contain a single model file named 'test.mydsl'. 'test.mydsl' is a model created based on the metamodel defined by the XText grammar in
I have not attempted to write ocl to validate an XText grammar (as in the CompleteOCL tutorial). |
|
By Ed Willink on Mar 26, 2024 14:03 (Messages crossed.) OK. I load Archive.zip "org.xtext.example.mydsl - fully generated" https://bugs.eclipse.org/bugs/attachment.cgi?id=289336 in my workspace, then open test.mydsl with MyDSL editor oops - no model elements This seems wrong and is presumably what you are reporting. (No need for any OCL.) Oddly the VV title reports one warning without displaying any actual warning, |
|
By Steve Hickman on Mar 26, 2024 15:15 Correct |
|
By Ed Willink on Mar 26, 2024 17:19 (In reply to Ed Willink from comment #18)
The VV is intended to help with constraints. It is clearly very unhelpful when it comes to diagnosing 'no constraints'. The default hide polarity of the hide constraintless/elementless toolbar buttons aggravates this. It is a bit of a fight but once test.ocl is loaded to accompany test.mydsl, a constraint and model element can be shown. The constraint fails, possibly due to the 'static def'. 'static' support is new, perhaps inadequately tested and certainly unnecessary / unconventional here. (When DSLs extend EObject, all the Ecore constraints ensure that there are plenty to consider.) |
|
By Steve Hickman on Mar 26, 2024 18:29 I went back after reading your last comment and loaded everything, after removing the 'static' from the def in 'test.ocl' . After clicking the 'Hide constraintless or deselected Model Elements' and 'Hide Model Element-less or deselected Contraints' buttons, I did manage to briefly see the Model Elements and Metamodel Constraints before getting this stack trace:
I then closed and reopened the runtime Eclipse. To eliminate possible interference from a different version of Eclipse that I also had running, I closed that (and the second Eclipse launched from it). I was then able to click the aforementioned buttons, select the 1 line of content in 'test.mydsl' : 'Hello Name!' and the OCL -> Load Document and load 'test.ocl'. I saw both the Model Element and the Metamodel Constraint and I did not get a stack trace this time (so that's good). However, attempting to 'Validate Selection' did nothing - and I tried from both the Model Element and Metamodel Constraints sides. Now I'll try after rebooting my machine and running only the Eclipse I'm testing (no browsers, or anything else) - and then report back. |
|
By Steve Hickman on Mar 26, 2024 18:58 Reboot and running without anything else appears to make things more stable - but it's only a few tests, so I can't be sure. I haven't seen any more stack traces or failures to create controls. The OCL test itself still fails to evaluate. The pop up says the 'constraint result is invalid' even though the OCL as written in the first Eclipse does not appear to have any errors. And I changed the call from to just to see if that made a difference. It didn't. One odd thing I did notice: When I use Cmd-Tab to tab through my open applications, it appears as though I have 2 runtime Eclipse's open in addition to my initial Eclipse. Don't know what's causing that. Is the VV one of those runtime Eclipses? |
|
By Steve Hickman on Mar 26, 2024 19:00 The multiple runtime Eclipses may be due to the LSP error I've previously posted above about. I got another one of those. |
|
By Steve Hickman on Mar 26, 2024 19:28 Based on this, I've gone back to the UDDL I originally mentioned. I can see the Model Elements and Metamodel Constraints in the VV if I do the following:
Apparently, selecting the contents of the model file ensures that the OCL will be applied to it. That's something I hadn't done before today. I did not click the 'Show constraint-less or deselected Model Elements' or 'Show Model Element-less or deselected Constraints' buttons with this approach. All constraints for which Model Elements exist result in 'Failed to evaluate' error. Don't yet know why. Constraints for which Model Elements do not exist are simply left with a ?. |
|
By Steve Hickman on Mar 26, 2024 19:30 One other thing: The 2 runtime Eclipses is probably not due to the LSP error. I got that LSP error again but only see 1 runtime Eclipse (+ the original Eclipse that launched it). |
|
By Ed Willink on Mar 27, 2024 04:06 The ergonomics of no-constraints clearly needs work. It is also not clear that the VV refreshes for all possible implied selection changes; clicks in the source model somethimes help. (In reply to Ed Willink from comment #20)
Removing the 'static' makes no difference. So something (different) to investigate here. Bug 583086 raised. Bugzilla goes read-only tomorrow. There is no adequate replacement. I regret that I lack the enthusiasm to chase the endless Eclipse Foundation infrastructure changes in my own time, so I'm standing down from OCL, QVTd and QVTo support. |
|
By Ed Willink on Mar 27, 2024 04:57 (In reply to Ed Willink from comment #18)
The warning message appears to be "Please select a model in the editor." but the ValidityView's messageManager contents are not shown. Is there a configuration/wiring error? Suggest creating a standard example project and see how the message manager works there. |
|
By Ed Willink on Mar 27, 2024 07:57 (In reply to Ed Willink from comment #26)
Thereafter communication will have to use https://www.eclipse.org/forums/index.php?t=thread&frm_id=26 except that FUDForum is also scheduled for termination. |
|
By Steve Hickman on Mar 28, 2024 15:10 Isn't the OCL source on Github? If so, can we use Github issues for bug reports? |
|
By Steve Hickman on Mar 28, 2024 16:09 I added a default Project Wizard and File Wizard to the MyDsl via the MWE2 file: and regenerated. I then started a second Eclipse and created a new project using the MyDsl Project Wizard. I opened the generated I then used OCL -> Show Validity View. Both the Model Element and the Metamodel Cosntraints showed content, but all were marked as 'failed to execute' immediately, even though I had not attempted to validate anything. I then exited the second Eclipse and moved In the (still open) Model.mydsl file, I did OCL -> Load Document and loaded Deselecting the content made things disappear from the Model Elements and Metamodel Constraints sections - and reselecting the content did not make it reappear. Further, after this closing the Validity View resulted in a parseResult error. |
|
By Ed Willink on Mar 28, 2024 16:16 These errors are all Bug 583086 OCL could be migrated to GitHub but migration of existing Buigzila content is inadequate. The webmaster has described the search capability as totally untrustworthy. I am not prepared to trash 20 years of reports / discussion and tight inter-project references, so I pass the baton to someone who is. |
|
By Ed Willink on Mar 28, 2024 16:23 (In reply to Ed Willink from comment #31) Strange, the read-only maintenance banner has been removed and comments work. Maybe we're back to normal. |
|
By Ed Willink on Mar 29, 2024 06:08 (In reply to Ed Willink from comment #20)
OCL->Load Document does not refresh the VV. Need to click the refresh icon explicitly or change the selection to another resource and back again. There is no attempt to auto-fresh since detecting a deep/transitive change affecting a metamodel/constraint could require costly ModificationTrackingAdapter hierachies and/or fragile dependency maintenance; user therefore has to refresh after undermining previous display. OCL->Load Document is nothing to do with the VV so the VV does not observe it. Consistent but unhelpful/confusing/disconcerting. If the VV monitored just the ResourceSet for new/old Resource changes, this could be helpful for OCL->Load Document, but confusing when the OCL document is edited. This rather conflicts with the typical use case: Set up models and any extras such as Complete OCL For big models the VV is probably pinned to avoid thrashing. The serious VV user should therefore know to refresh and won't do late OCL->Load Document anyway. The real problem here is that 'no-constraints' gives a blank VV which the late OCL->Load Document doesn't unblank without a refresh. If the VV was not blank, the lack of extra constraints would be less disconcerting and the user could be more motivated to refresh. |
|
By Ed Willink on Mar 29, 2024 11:15 (In reply to Ed Willink from comment #27)
Example project no help; doesn't use Form. Examining Form, there is a FormHeading for which ensureMessageRegionExists() should is called by showMessage from setMessage. After debugging, a messageRegion is created and the message is applied. Ah! it is 'visible' as the tooltip/hover-text on the form heading icon / warnings detected message. Sensible and consistent, but it beat me. Tough, nothing to fix here. |
|
By Ed Willink on Mar 29, 2024 11:39 (In reply to Ed Willink from comment #33)
After changing the show/hide defaults to show and fixing constraintless elements to be potentially visible, it's all a lot better. (A UML user will no doubt learn to create a blank VV and disable show before gratuitously analysing large numbers of metamodel elements.)
If the VV user is expected to refresh to catch up on concurrent changes, why do we have a not-pinned option that by default chases the selection and burns time refreshing the VV when a chnage was not wanted. Is there a use case for a VV update as soon as the cursor selects? Surely not. If we get rid of not-pinned the user will get a consistent nothing chnages till a refresh ergonomic. |
|
By Ed Willink on Apr 02, 2024 05:14 (In reply to Ed Willink from comment #35)
So the VV always starts with disconcerting blank content. This is good when Eclipse is starting since it is very unlikely that a user wants to burn start up cycles repopulating the VV from some stale selection. We can replace the blank content with welcome messages explaining the clearer select-then-refresh ergonomic and the unconstrained element hiding. The default can therefore revert to hide unconstrained. |
|
By Ed Willink on Apr 02, 2024 07:39 https://ci.eclipse.org/ocl/job/ocl-branch-tests/386/artifact/releng/org.eclipse.ocl.releng.build-site/target/repository/ has a successful build that hopefuilly fixes all these issues. JUst some tidying/testing to go. |
|
By Ed Willink on Apr 16, 2024 04:13 (In reply to Ed Willink from comment #37)
Trying to follow the Validation Tutorial, we have some way to go. The 'new' Complete OCL Loader highlights that the EnvironmentFactory creation doesn't exploit a pre-existing loaded ResourceSet so the Complete OCL doesn't load usefully. Once that is fixed, we hit the 'for fuller compatibility we need' comment in Bug 582494. If the EMF Validate is to work with OCL added value, the global validation registry has to be enhanced (unless a better Diagnostician construction occurs). |
|
By Ed Willink on Apr 23, 2024 06:11 (In reply to Ed Willink from comment #38)
Once that is fixed testValidate_Validate_completeocl fails becuase on its second 'pass' the externalResourceSet already contains the Complete OCL, but the re-use fails to perform the required cs2as to ensure that the AS constraints are installed. Once that is fixed we get a repro for the bad *.oclas ResourceSet intermittency. |
| --- | --- |
| Bugzilla Link | 583043 |
| Status | NEW |
| Importance | P3 normal |
| Reported | Mar 18, 2024 13:12 EDT |
| Modified | Apr 23, 2024 06:11 EDT |
| See also | 583086, 583088, 583185 |
| Reporter | Steve Hickman |
Description
I installed the following in this order:
I then opened some existing XText based DSLs (2: UDDL Query and UDDL. UDDL depends on UDDL Query) and rebuilt (Project -> Clean & Rebuild). There were warnings and infos, no errors.
I then created a runtime configuration using defaults (all plugins) and started it. In the new workspace, I created a default UDDL project with a default .uddl file. The default file is syntactically correct. I then copied some predefined model files with lots of content into the project - including content for metamodel elements that have OCL invariants defined.
I then did the following:
The Validity View does not display model elements or constraints
I believe the test DSL from prior ValidityView bugs should have the same problematic behavior. If they don't, link them here so I can try them out/ look at them and I'll create a minimal test DSL that exhibits the problem behavior.
FWIW, I've also sent you an invite to the Github repos I used.
The text was updated successfully, but these errors were encountered: