The problem is that *.facetset files are loaded into the FacetSetCatalog and on to the global EPackage.Registry. Very very naughty. Application A affects application B.
Bring a good Eclipse citizen requires that
If running App A followed by App A gives the 'same' results, then interjecting an execution of MoDisco between the App A runs must not upset the 'same'ness.
Since MoDisco corrupts the global EPackage.Registry between the App A runs, MoDisco is not a good Eclipse citizen.
Possible solution.
Just like the EPackage.Registry:
the global FacetSetCatalog is populated by extension points
the local FacetSetCatalog (perhaps a ResourceSet.eAdaper) is populated dynamically and delegates to the global.
If FacetSetCatalog entries must also appear in the EPackage.Registry then stadard EMF registrations are needed, albeit to fake EPackage registration classes (cd the OCL stdlib registration.)
| --- | --- | | Bugzilla Link | 559265 | | Status | NEW | | Importance | P3 blocker | | Reported | Jan 16, 2020 11:05 EDT | | Modified | Jan 17, 2020 09:26 EDT | | Depends on | 415835 | | Reporter | Ed Willink |
Description
From Bug 559205
The problem is that *.facetset files are loaded into the FacetSetCatalog and on to the global EPackage.Registry. Very very naughty. Application A affects application B.
Bring a good Eclipse citizen requires that
If running App A followed by App A gives the 'same' results, then interjecting an execution of MoDisco between the App A runs must not upset the 'same'ness.
Since MoDisco corrupts the global EPackage.Registry between the App A runs, MoDisco is not a good Eclipse citizen.
Possible solution.
Just like the EPackage.Registry:
the global FacetSetCatalog is populated by extension points
the local FacetSetCatalog (perhaps a ResourceSet.eAdaper) is populated dynamically and delegates to the global.
If FacetSetCatalog entries must also appear in the EPackage.Registry then stadard EMF registrations are needed, albeit to fake EPackage registration classes (cd the OCL stdlib registration.)