Community
Participate
Working Groups
This thread started to avoid initial discussion on the desirability of this migration clouding discussion of feature/plug-in reorganisation. --- Semantic validation by OCL editor requires a package path so that the reference to e.g. MyPackage::MyClass can be resolved to MyPackage in MyModel.ecore. This trivial problem is currently resolved by the M2M/QVT Declarative OCL editor by exploiting the M2M/QVT Declarative Model Registry. If the M2M/QVT Declarative OCL editor is migrated to MDT/OCL, a solution to this problem must be found. It is obviously possible to emulate other projects with a solution satisfying the immeditate requirement only. The more general solution provided by the Model Registry should be of benefit to many projects. I have not met with great success in my attempts to create an EMF Registry project since Ed Merks perceives this as a uniquely OCL, QVTd problem. While an EMF Registry would maximise re-use, MDT/OCL is widely used, so an MDT/OCL Registry could be nearly as easily re-used by a wide variety of modeling projects. I therefore recommend migration of the M2M/QVT Declarative Model Registry to MDT/OCL. I will post code if the team is happy with this proposal.
Hi Ed, +1. This is the faster/easier way to solve the issue of being able to introduce a nice OCL text editor. What are you finally doing with the IMP project dependent stuff?. P.S: I'm sorry for not being able (honestly, I'm too busy right now) to write some lines to your proposal which IMO makes sense. In any case, I also believe that it had been useless, and from our needs having such stuff in MDT-OCL would suffice. Cheers, Adolfo.
+1. I agree that this is the easiest way to make the functionality available for OCL (and downstream projects), though I think it is not related to the OCL language itself. In QVTO there is a similar registry for workspace metamodels. Reusing the corresponding OCL functionality (when it appears) would be preferrable.
The QVTo registry is actually completely different. At EclipseCon 2008 both were presented and it seemed a good idea to merge the facilities. I had started to look at the QVTo Model Browser for incorporation into the EMF Registry, but decided to leave it out of the OCL Registry to avoid inflicting too much unwelcome bloat. If the team want to provide a more comprehensive Registry UI, I am happy to include it. I think there are some laziness optimisations that can avoid loading every possible Ecore file; this may be why MaxPermSize has become such a problem. If every Workspace and Platform Ecore file really must be loaded, it would be good to provide a single ResourceSet that contains them all. I suspect that each of at least EMF Index, QVTo and ATL may be doing this independently. Could you use your Borland contacts to request permission to use the QVTo code as the basis for a mark II Model Browser? Could you please find out what the important rather than notional APIs are? I suspect the Model Browser is just a GUI tool and DND source. Trivial issue. Should the OCL Registry plugins be 0.7 or 3.0? (Ditto the OCL Editor)
Done as part of examples.
Closing
