eclipse-amalgam-bot
commented
2 years ago nicolas.rouquette commented on 2009-01-22
I encourage you to consider this:
With DSLTK 1.0.0M4 + a few updated components, it runs just fine.
In fact, it would be great if we could use the DSLTK itself to configure/generate a textual editor for OCL documents we can load in the OCL Environment console.
christian.damus commented on 2009-01-22
(In reply to comment #1)
In fact, it would be great if we could use the DSLTK itself to configure/generate a textual editor for OCL documents we can load in the OCL Environment console.
This is just an example and, as such, is not intended to be supported in any of the Amalgamation productoids. The OCL committer team cannot formally support this in the Galileo release.
Note also that Ed Willink and I are hatching plans to bring his *.ocl editor into the MDT OCL component. Again, this would be a post-Galileo target.
nicolas.rouquette commented on 2009-01-22
Where are these plans being hatched? I tried to use the textual OCL Editor that Ed Wilink has been working on in OAW/UMLX with the DSLTK 1.0.0M4 but I had problems with the IMP plugin dependencies.
christian.damus commented on 2009-01-22
(In reply to comment #3)
Where are these plans being hatched? I tried to use the textual OCL Editor that Ed Wilink has been working on in OAW/UMLX with the DSLTK 1.0.0M4 but I had problems with the IMP plugin dependencies.
Sorry, Nicolas. I guess I overstated the situation. Ed and I have been discussing, off-line, his future involvement with the OCL project, and the editor is something that looks promising.
In any case, his editor now resides in the M2M QVTr project, if I'm not mistaken, and it should be fairly current there.
nicolas.rouquette commented on 2009-01-22
What does "QVTr" refer to?
There are several things ocl-related amongst the org.eclipse.m2m.qvt plugins. DSLTK (the galileo version) includes the org.eclipse.m2m.qvt.oml.sdk feature. Which of these will have Ed's editor?
christian.damus commented on 2009-01-22
(In reply to comment #5)
What does "QVTr" refer to?
There are several things ocl-related amongst the org.eclipse.m2m.qvt plugins. DSLTK (the galileo version) includes the org.eclipse.m2m.qvt.oml.sdk feature. Which of these will have Ed's editor?
I was think of the org.eclipse.m2m.qvt.declarative module (QVTr == QVT Relations == QVT Declarative) but in a quick look, I don't see an OCL editor in there. So, maybe it still is in UMLx?
adolfo.sanchez-barbudo.herrera commented on 2009-01-23
Hi guys,
to make QVTDeclarative's OCL Editor work, you could try the following steps:
Eclipse 3.5 (M4) EMF 2.5(M4) MDT OCL 1.3 (CVS Head) M2M QVT Declarative (CVS Head) The following package from LPG project CVS (:pserver:anonymous@lpg.cvs.sourceforge.net:/cvsroot/lpg): lpg.runtime.java The following packages from IMP SVN (https://dev.eclipse.org/svnroot/technology/org.eclipse.imp): org.eclipse.imp.runtime org.eclipse.imp.smapi org.eclipse.imp.smapifier
You will also have to get an extra package from wala project SVN (https://wala.svn.sourceforge.net/svnroot/wala): *com.ibm.wala.shrike
Finally, you will have to apply a patch which resides in a QVT Declarative project to fix some IMP problems: *org.eclipse.qvt.declarative.parser.IMPruntime20742.patch
It's possible that some classes in the IMP projects were still missing. The problem would be that they have to be generated by the LPG, executing LPG v2 generator on some grammar files). In that case you will have to download two projects into your workspace: lpg.generator.win32_x86 (provides the generator). org.eclipse.imp.lpg.metatooling (provides a needed templates folder).
Then, select the grammar file (i.e, org.eclipse.imp.preferences.PreferenceValueParser.g in the imp.runtime project), execute "external tools" -> lpg (the launchConfiguration comes from lpg.runtime.java proeject, so you should have it), and the missed classes should come up.
I hope the info helps.
P.S: the ocl editor is in the org.eclipse.qvt.declarative.editor.ocl.ui project, though, it uses a lot of common infrastructure in other projects P.S2: I have also added Ed to the bug, so that, he can correct anything I have missed.
Cheers, Adolfo.
org.eclipse.imp.lpg.metatooling
ed.willink commented on 2009-01-26
Thanks Adolfo. A good description of from CVS.
The IMP patch is useful but not mandatory.
--
Alternatively a binary only update can be found in the first QVT Declarative build at
http://download.eclipse.org/modeling/m2m/qvt_declarative/updates/
It provides a redistribution of the more awkward plugins allowing a direct update of an Eclipse 3.5M4 + EMF, EMF-Query, EMF-Validation, EMF-Transaction, MDT-UML2, MDT-OCL.
The 'all parsers and editors' feature is sufficient for OCL editor support.
The above dates from October 2008.
The CST/AST navigation and BacktrackingParser support are in CVS Head for M5, so that a much cleaner build will be available shortly after M5. The editor outlines are now much prettier too.
The editor is being used in earnest.
org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.eclipse.qvt/oclsrc/QVTRelation.ocl (600 lines) was developed with it.
The rest of the project may provide clues as to how the Model Registry ensures that the above can find the QVT meta-models for semantic validations.
nicolas.rouquette commented on 2009-01-30
To use IMP in 3.5M4, I had to bring fromthe repositories Adolfo mentioned the following projects:
com.ibm.wala.shrike lpg.generator lpg.generator.${target.os}_${target.arch} org.eclipse.imp.lpg.runtime org.eclipse.imp.metatooling org.eclipse.imp.preferences org.eclipse.imp.prefspecs org.eclipse.imp.runtime org.eclipse.imp.smapi org.eclipse.imp.smapifier org.eclipse.imp.xform
I installed the IMP binaries to run the code generator but I managed to run with the above plugins modulo just two fixes (besides adjusting the MANIFEST.MF accordingly):
- FilteredTypesSelectionDialog replaces the deprecated TypeSelectionDialog2 in org.eclipse.imp.wizards.IMPWizardPage
- There is a small typo in org.eclipse.imp.wizards.NewProjectWizardSecondPage (line 132)
I managed to get the OCL editor up and running. I like the per-project registration mechanism for resources.
However, it seems that org.eclipse.qvt.declarative.editor.ocl.ui expects a project to register ECore metamodels, not UML metamodels.
When I register a UML metamodel in my project and load an OCL file, the OCL editor creates an OCL environment that includes all of the project-registered metamodels. I followed what happens to this method:
org.eclipse.qvt.declarative.parser.ocl.environment.OCLTopLevelEnvironment.addToPackagePath(EList<? extends EObject>, String)
As long as the registered metamodel is an ECore metamodel, then this method will add all of the packages of that metamodel. However, if I register a *.uml metamodel resource, this method will not find any UML package because such packages aren't instances of EPackage.
Is there a way to use the QVT declarative OCL editor with UML metamodels rather than ECore ones?
ed.willink commented on 2009-01-31
Reply to build comment
It is only necessary to have
com.ibm.wala.shrike org.eclipse.imp.runtime org.eclipse.imp.smapi org.eclipse.imp.smapifier
as long-term open projects. In order to build the IMP Preferences grammar it is temporarily necessary to have
lpg.generator lpg.generator.${target.os}_${target.arch} org.eclipse.imp.lpg.metatooling
open. org.eclipse.imp.lpg.metatooling will show errors from missing dependencies, but it is only used to provide include files, so the errors do not matter. You can close org.eclipse.imp.lpg.metatooling once you have the missing Java files. I have raised ECLIPSE-262872 to get IMP to provide Java in CVS in the same way as EMF and MDT-OCL.
Reply to UML comment
A very timely request. I've just been fixing the OCL (editor) to support non-navigable opposites in Ecore/EMOF, which wouldn't be a problem in UML and wondering how UML support would work. A revision of the model registry and a proposal for a separate project is in the offing. If you could send me your UML files and OCL constraints that you'd like to work, I'll take a shot at it. I've never used Eclipse UML tooling so any help is welcome.
ed.willink commented on 2009-02-02
More detailed reply to UML meta-models for OCL editor.
As you observe: the Model Registry provides the registered resource (UML or Ecore or whatever), the OCL Editor is an Ecore-binding and so only handles Ecore meta-models
a) you can manually convert UML to Ecore using UMLUtil.convertToEcore or GUI b) the Model Registry could do this if it knew about UML and was asked for Ecore c) the OCL editor could do this if it knew about UML
but for b) and c) where should the Ecore file be persisted in order to persist the edited OCL?
d) Alternatively the OCL editor could have distinct Ecore and UML bindings, so that UML meta-models were used automatically, but this gives the opposite problem of where UML conversions of Ecore are to be persisted.
e) Alternatively again the UML to Ecore conversion could use the EMOF to Ecore conversion via adapters approach so that the UML and Ecore objects were apparently the same information object with a shared URI. The OCL editor would then be unaware of the external representation of its internal EPackage, EClass, ... This would require that any downstream tooling also used this approach.
a) is clumsy, d) or e) are more work than I have time for. b) or c) are quite easy. b) is more flexible.
So I'm inclined to do b) but as a UML user do you have opinions about where Ecore files be auto-generated and how they might be updated? Perhaps if the Ecore file has the UML URI internally, the OCL persistence can reference the UML as in e) avoiding the need to ever persist the Ecore.
nicolas.rouquette commented on 2009-02-03
1) For UML models, you can get plenty of OCL here:
org.eclipse.mdt/org.eclipse.uml2/plugins/org.eclipse.uml2.uml/models
Infrastructure.uml is a self-contained resource. Superstructure.uml depends on Infrastructure.uml
In my biased opinion, we'd be better off organizing all of the OCL content of the UML using a Java-like correspondence between packages and folders. For example, one could conceivably organize the OCL content of the UML kernel in a folder: UML/Classes/Kernel/
There, we could either group OCL content as a huge package document, split it by class or group according to, e.g., the package diagrams (i.e., Root, Namespaces, Classifiers, etc...)
At least, this is the approach I'd like to use for the Metamodeling Specification Tools project in Eclipse.
2) For a concise example of an OCL document for a given model, consider the following:
org.eclipse.mdt/org.eclipse.ocl/tests/org.eclipse.ocl.uml.tests
The model directory includes a sample model (OCLTest.uml) that is loaded here: org.eclipse.ocl.uml.tests.AbstractTestSuite.initFruitPackage()
org.eclipse.ocl.uml.tests.OCLDocumentTest exercises the OCL parser/evaluator based on the model/test_constraints.ocl document.
3) For maximum flexibility w.r.t. using your OCL editor for various metamodels (ECore, UML, etc...), I definitely recommend considering the strategy Christian used for the revamped OCL console example: ECLIPSE-259922
I'm using this with my 3.5M4+ sandbox. It works just fine but it would be even better if we could use it in conjunction with your editor -- i.e., use the textual editor to hack OCL with agile impunity and use the OCL console as a decent front end for invoking queries/helpers and last minute OCL hacks that we can save in an OCL document again. Now, this would be uber cool. True nirvana would be to have a similar capability for using Alloy. Then, with the flexibility to use OCL or Alloy depending on the needs of the problem, I really don't know what else to ask for except perhaps for an integration with a theorem prover that can dig OCL and/or Alloy directly.
christian.damus commented on 2009-02-03
(In reply to comment #11)
More detailed reply to UML meta-models for OCL editor.
As you observe: the Model Registry provides the registered resource (UML or Ecore or whatever), the OCL Editor is an Ecore-binding and so only handles Ecore meta-models
What would it take (effort, code churn) to make the editor support the UML metamodel binding? Ideally, it would be open to user-defined bindings as the rest of the OCL API is ...
Well, probably not "ideally." I think it would be expected.
a) is clumsy, d) or e) are more work than I have time for. b) or c) are quite easy. b) is more flexible.
So I'm inclined to do b) but as a UML user do you have opinions about where Ecore files be auto-generated and how they might be updated? Perhaps if the Ecore file has the UML URI internally, the OCL persistence can reference the UML as in e) avoiding the need to ever persist the Ecore.
But, all of these approaches translate the UML to Ecore, which is lossy and renders UML-based (CompleteOcl) constraints infeasible. Support for metamodels expressed in the UML is needed in both the registry and the editor ...
ed.willink commented on 2009-02-03
It's only software. In principle it just requires migrating the mega-genericity throughout the editor environments and then terminating them with distinct Edcore and UML concrete classes. How long did it take you to create the UML-binding once the Ecore-binding was done? Not necessarily difficult, but not a great deal of fun; I was hoping for something more interesting after wading through missing QVT constraints.
In practice we would end up with two OCL editors, which is at best confusing for users, who are only interesting in constraining the modeled Class Fred, regardless of whether the underlying representation is UML or CMOF or EMOF or Ecore or ...
I think that a more widespread discussion is needed to decide how multi-dialect meta-models should co-exist so that OCL tooling and Model Registries support an agreed consensus.
Perhaps we need an ExtendedEcore/TrimmedUML/Ccore, perhaps using my adapters approach, so that a single ExtendedEcore object is available for every meta-model concept with adapters providing alternate views for meta-model dialects. An extended Ecore is presumably necessary to ensure that the relevant parts of UML are handled losslessly. What important UML concepts are lost in Ecore?
ed.willink commented on 2009-02-05
Two OCL editors is obviously daft, so the OCL editor should use the UML binding to ensure lossless behaviour on richer UML meta-models. So the OCL tooling must be generic to allow derived QVT editors to extend the Ecore binding.
At present the editor invokes the ModelRegistry's ModelResolver.getResource method to obtain a registered resource which currently needs to be Ecore since that is what the tool (the current OCL editor) requires.
The ModelRegistry needs additional ModelResolver.getEcoreResource and ModelResolver.getUMLResource methods to normalise the meta-model presented to consuming tools. These can use UMLUtil.convert methods.
Then with the OCL editor UML-based, and invoking ModelResolver.getUMLResource to obtain its meta-models, a mixture of Ecore and UML meta-models should work, and if the Ecore conversion supports the Ecore oppositeRoleName annotation (UML2 patch probably required), the OCL editor will support unnavigable opposites on Ecore meta-models without introducing an additional OppositePropertyCallExp to ocl.ecore.
The org.eclipse.ocl.edit and org.eclipse.ocl.ecore.edit plug-ins are currently in QVT Declarative's CVS. Are you happy for development of the generic editor to use the org.eclipse.ocl.uml.edit, org.eclipse.ocl.editor, org.eclipse.ocl.ecore.editor, org.eclipse.ocl.uml.editor, org.eclipse.ocl.editor.ui, org.eclipse.ocl.ecore.editor.ui, org.eclipse.ocl.uml.editor.ui plugin names and related package names again in in QVT Declarative's CVS, pending a post-Galileo migration?
christian.damus commented on 2009-02-06
(In reply to comment #15)
Ah, I see that your answer to your own question is much as mine would have been, had I been quicker off the mark. :-)
Two OCL editors is obviously daft, so the OCL editor should use the UML binding to ensure lossless behaviour on richer UML meta-models. So the OCL tooling must be generic to allow derived QVT editors to extend the Ecore binding.
Right. This was one of the main goals of the OCL Console example, to demonstrate how a clinte of the parser can pass along the generic capability of supporting any metamodel binding over to its own clients. I think the revised edition does a better job of that ...
At present the editor invokes the ModelRegistry's ModelResolver.getResource method to obtain a registered resource which currently needs to be Ecore since that is what the tool (the current OCL editor) requires.
The ModelRegistry needs additional ModelResolver.getEcoreResource and ModelResolver.getUMLResource methods to normalise the meta-model presented to consuming tools. These can use UMLUtil.convert methods.
Or, can ModelResolver.getResource just not return whatever the resource is in its native format? A client may not be looking for a specific metamodel, but may have a means (as in the new console example) of discovering a plug-in that supports it.
Then with the OCL editor UML-based, and invoking ModelResolver.getUMLResource to obtain its meta-models, a mixture of Ecore and UML meta-models should work, and if the Ecore conversion supports the Ecore oppositeRoleName annotation (UML2 patch probably required), the OCL editor will support unnavigable opposites on Ecore meta-models without introducing an additional OppositePropertyCallExp to ocl.ecore.
I don't envision an OCL editor that is UML-based, just generic as the console is. Whatever environment implementation it discovers that handles the resolved model obtained from the registry will know what level of OCL compliance it provides, and it parses the text accordingly.
The org.eclipse.ocl.edit and org.eclipse.ocl.ecore.edit plug-ins are currently in QVT Declarative's CVS. Are you happy for development of the generic editor to use the org.eclipse.ocl.uml.edit, org.eclipse.ocl.editor, org.eclipse.ocl.ecore.editor, org.eclipse.ocl.uml.editor, org.eclipse.ocl.editor.ui, org.eclipse.ocl.ecore.editor.ui, org.eclipse.ocl.uml.editor.ui plugin names and related package names again in in QVT Declarative's CVS, pending a post-Galileo migration?
Yes, that's fine by me. We can migrate the whole works, then, to resolve a number of outstanding enhancement requests in the UI department. Thanks!
richard.gronback commented on 2009-02-06
Perhaps we can move this larger discussion to a bug of its own? My original purpose for this bug was to simply add the current OCL console example in the DSL Toolkit, which I have done. Later, I'd be happy to include what has been discussed here.
ed.willink commented on 2009-02-06
OCL editor discussion continued in Bug #263975.
Sorry I thought this was an OCL rather than Amalgam thread.
richard.gronback commented on 2009-02-06
No problem, I'm glad it spurred the conversation.
Closing now, as OCL Interactive console is in the latest DSL Toolkit I-build.
A useful utility that is somehow missing from the current config.
🆔 ECLIPSE-261742👷 richard.gronback📅 2009-01-20