[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-ocl.dev] OCL Pivot Promotion for M5
|
Hi
On 26/12/2014 22:22, Ed Willink wrote:
org.eclipse.ocl.pivot is the public API, vaguely corresponding to
org.eclipse.ocl.examples.domain
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.
Regards
Ed Willink
