eclipse-ocl-bot
commented
1 week ago By Ed Willink on Aug 18, 2017 06:27
commit 62cece163f9aedc49cc1433361ea230e1d1af630 pushed to master for Photon M2
improves the timing of import resolution to lie between creation and reference rsolution. May help some legacy wierdnesses.
| --- | --- | | Bugzilla Link | 520847 | | Status | NEW | | Importance | P3 normal | | Reported | Aug 10, 2017 10:24 EDT | | Modified | Aug 18, 2017 06:27 EDT | | Blocks | 510503 | | See also | 466620, 415146 | | Reporter | Ed Willink |
Description
Originally we had distinct library/import statements, but since import has evolved to load any Pivot-based AS/CS "library" is redundant.
To allow Pivot tooling for Pivot metamodels we have some magic load/install functionality that has grown and grown.
Bug 415146, Bug 466620 and Bug 510503 all seem to be influenced by library loading vagueness.
Default use case. Load standard Pivot, standard OCLstdlib. Happens via PivotStandaloneSetup.init().
Extended use case. Load eg. QVTr pivot, QVTr stdlib. Happens via QVTrStandaloneSetup.init anided by QVTrEnvironmentFactory specifying the default stdlib contribution.
Variant library use case. User must contrive to specify variant library and pivot is lazy to facilitate this.
Variant pivot use case. User references workspace *.ecores.
Variant library + variant pivot use case. Is this needed? Surely the variant library specifies its corresponding pivot.
The pivot metamodel should be loaded first since it does not need the library until it resolves body expressions.
The library metamodel must be loaded after the pivot to resolve e.g. metatypes.
Is it sufficient to just require that for the variant library use case, the variant library must be the first import, setting library-load-in-progress flags, while the variant library's imports find the perhaps variant pivot?
With a simple policy we can perhaps have much better diagnostics about loading potentially schizophrenic models.