| Best practice for metamodels under development [message #1858084] |
Wed, 15 March 2023 10:31  |
|
Registering changing versions of ePackages in the global registry during runtime is discouraged, as it has the potential to disrupt consistency. Prior clients can suddenly find that a EPackage has change while they were not looking.
However, it seems that EMF allows dynamic registrations using the computePlatformURIMap() method for the purpose of active development.
This method seems to allow unifying all accesses to resources under a schema of platform:/resource/<pluginId> and then redirects the accesses using folder mappings to either the workspace or the active target platform, ultimately resolving them as directories or archives.
Since this method requires a registration of the map in the resource set to become effective, I am wondering if it is available through a menu or command anywhere in the core EMF tooling.
I am further wondering if there any known tool sets building on EMF that are using and/or exposing this feature. It looks very useful, but I have never come across it in practice.
Any information would be welcome.
|
|
|
|
|
| Re: Best practice for metamodels under development [message #1858146 is a reply to message #1858101] |
Fri, 17 March 2023 09:53  |
 Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
For most purposes EMF supports local ResourceSet registries that delegate to the global registry. This enables disciplined applications to install suitable local registrations without disrupting others. The notable exception is the lack of a local ValidatorRegistry forcing OCL and Xtext to play games with Composites. Messing with the global registry is not discouraged, it should be regarded as forbidden.
For OSGI usage within Eclipse the "platform:" part of the URI is a satisfactory virtual location that successfully unifies the diverse roots that result from GIT projects.
For standalone usage there is no corresponding "platform:" and so diverse tools have pragmatic solutions to try to make "../.." navigation work. The Acceleo solution is quite dreadful ensuring that most non-trivial accesses fail. Xtext works provided you don't need to access the grammar as an EMF Resource. QVTo has had some significant fixes recently. OCL works hard via its ProjectMap to create the virtual location. EMF's addition of an ExtensionsProcessor goes a long way to solving the problems but it is not complete.
At the risk of flogging a dead horse, IMHO, one of EMF's greatest design mistakes was to support loading models by physical location as well as, rather than just, by model name thus allowing multiple variants of the 'same' EPackage.nsURI in the same ResourceSet. OCL's ProjectMap works hard to eliminate this schizophrenia by suppressing extra variants and redirecting to the one. However it can be tricky to get the ProjectMap initialization right so that sometimes it seems like the cure is as bad as the disease. In principle an application just wants to make consistent use of the model registered as the character string "http://www.eclipse.org/emf/2002/Ecore". Whether this comes from Java code, project, or plugin Ecore files could be irrelevant to the application. This physical location polymorphism is one of EMF's best features. However the resolution thereof should be just a detail for the model loader. If an application really needs multiple versions of the same model, then multiple ResourceSets could provide the solution.
There are certainly opportunities for EMF's standalone support to be better, but legacy/consensus/funding challenges ensure that none will be found.
|
|
|
Powered by
FUDForum. Page generated in 0.03213 seconds
] 
Search
Help
Register
Login
Home
