Re: [mdt-ocl.dev] MDT-OCL project organisation for add-ons (editor etc)

[Ed Willink <ed@xxxxxxxxxxxxx>]

Hi Alex

It's not easy at all. Many IMP classes provide useful base class 
functionality, and many of its interfaces are used in function 
signatures. A simple wrapper providing name-occluding derived classes 
gives erroneous types. It would be necessary to put a delegating wrapper 
around every re-used interface, and change the types in all affected 
functions. Trying to find a boundary between the useful and probably not 
used parts of IMP runtime is very difficult. Everything looks like it 
ought to be useful.

A much easier solution. Since IMP runtime no longer has any nasty 
dependencies of its own, we just ship a lib/imp.jar in the abstract 
editor plugin. The jar contains a bug-fixed org.eclipse.imp.runtime 
plug-in. Derived editors will see the org.eclipse.imp.runtime. No one 
else will.

The jar is just over 1MB so it's not too bad to treat it as a CVS source.

Suggested plugin names.

org.eclipse.ocl.edit - EMF generated edit functionality
org.eclipse.ocl.editor - EMF generated editor functionality
org.eclipse.ocl.editor.ui - abstract editor functionality
org.eclipse.ocl.ecore.editor.ui - OCL editor wth Ecore binding
org.eclipse.ocl.uml.editor.ui  - OCL editor wth UML2 binding

and

org.eclipse.ocl.editor-feature

The UI capabilities should allow either Ecore or UML2 or both bindings 
to be disabled.

The plug-in should work with 1.3.0, so as a pure add-on we could offer 
it for 1.3.1 apart from the Model Registry problem. Sven assures me that 
this is within the scope of EMF Index and already available. I can't 
find any documentation so it's hard. Hopefully the QVT Declarative Model 
Registry can be contributed to EMF Index in some useful way.

   Regards

      Ed Willink


ed@xxxxxxxxxxxxxxxxxx wrote:
> Hi Alex
>
> After some thinking, not using IMP will solve many problems.
>
> Currently relatively little of IMP's capabilities are actually used. IMP
> was very useful in showing how some problems were tackled, but a little
> irritating in its failure to fix problems.
>
> It should be quite easy to first put a wrapper around IMP, then
> reimplement directly on SWT within that wrapper. When IMP is stable and/or
> offers sufficient added value we can revert to using IMP.
>
> No problems with external dependencies on IMP or LPG 2. We just have a
> significant extension to OCL that is not described as Incubation. We may
> just need a significant IPlog credit to IMP if I cut and paste larger
> parts of IMP code.
>
>     Regards
>
>          Ed Willink
>
>
>   
> > Hi Alex
> >
> > I forgot to mention; The current QVT Declarative CVS uses the OCL Ecore
> > binding. My development version uses the OCL UML binding and automatically
> > converts Ecore or EMOF meta-models to UML so that the editor works any any
> > normal representation.
> >
> >      Ed
> >
> >
> >
> >
> > _______________________________________________
> > mdt-ocl.dev mailing list
> > mdt-ocl.dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
> >
> >     
>
>
>
>
>