Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] OCL Pivot Promotion for M5


On 26/12/2014 22:22, Ed Willink wrote:
org.eclipse.ocl.pivot is the public API, vaguely corresponding to
org.eclipse.ocl.pivot.internal is the less public API, vaguely
corresponding to org.eclipse.ocl.examples.pivot
This doesn't work realistically for users.

While ...pivot.internal depends on ...library depends on ...pivot seems to provide a potential for lightweight reuseable interfaces, it is unnatural. and it needs a genmodel tweak to put interfaces and implementations in different plugins.

PivotPackage, PivotFactory have to be in the internal plugin as does anything else that creates a Pivot object, so in practice use of just the public API is useful only for readonly analysis/execution of an OCL AS tree built elsewhere (e.g. by an editor). No creation is un-EMF.

The intent of the lightweight reuseable interfaces has been to provide polymorphism for code generated code. Originally with those irritating DomainXXX classes, now with the partitioned model plugins. The most important customer is UML2 for which a dependency on OCL is very undesirable, so the lightweight interfaces probably don't help.

CG for UML2 is closed world, i.e. no ability to extend with extra Complete OCL documents, so for most UML2 functionality it can be just linear Java; it is only for oclType()/oclIsKindOf() that a partial OCL type system is needed. Therefore we can have a closed world CG that will do most of UML2 with an option to either auto-generate a type system run-time within the generated artefacts or to reference a shared version from OCL.

So, since the struggle to provide lightweight reuseable interfaces doesn't work for the most important use case and creates un-EMF characteristics for normal users, why bother?

...pivot.internal and ...library are therefore merged into ...pivot giving a single non-UI plugin within which we can distinguish public/internal functionality using exports/packages names.


Next, splitting off UML support so that it is truly optional. As a minimum this requires a ...pivot.uml plugin. In more detail it needs extensibility so that derived UML-specific classes are used when UML is required and so that UML-specific classes are created automatically.

The key to discovering what the user needs is the Resource class (is it a UMLResource) for which the ASResourceFactoryRegistry has sensitivities. Just need to make its population be via an extension point. Thereafter the ASResourceFactoryRegistrycn create an appropriate deruved AbstractEnvironmentFactory where new methods such as createMetamodelManager etc can be found. (I have finally corrected the "MetaModel" spelling error).

Construction flow is now typically

ResourceSet -> OCL -> EnvironmentFactory -> MetamodelManager


I've pruned some of the totally dead confusing functionality and made some other functionality such as Customizable/Adaptable a bit more plausible. The old Environment class vanishes completely, which is handy with a new one on the way.


        Ed Willink

Back to the top