[registry] Migrate the M2M/QVT Declarative Model Registry to MDT/OCL

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 289759 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | Sep 17, 2009 11:27 EDT | | Modified | May 27, 2011 02:54 EDT | | Version | 1.3.0 | | Blocks | 220218 | | Reporter | Ed Willink |

Description

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.

[eclipse-ocl-bot]

By Adolfo Sanchez-Barbudo Herrera on Sep 17, 2009 12:00

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.

[eclipse-ocl-bot]

By Alexander Igdalov on Sep 18, 2009 04:31

+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.

[eclipse-ocl-bot]

By Ed Willink on Sep 18, 2009 14:47

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)

[eclipse-ocl-bot]

By Alexander Igdalov on May 27, 2010 16:02

Done as part of examples.

[eclipse-ocl-bot]

By Ed Willink on May 27, 2011 02:54

Closing