Home » Modeling » EMF » API-level facility for dynamic models(Does a project have to implement dynamic ePackage registration?)
| API-level facility for dynamic models [message #1858012] |
Sat, 11 March 2023 01:10  |
|
The EP org.eclipse.emf.ecore.dynamic_package provides dynamic ePackage loading from a resource. It implements through method org.eclipse.emf.ecore.plugin.RegistryReader.EPackageDescriptor.Dynamic.getEPackage(),
RegistryReader.EPackageDescriptor.Dynamic has default visibility and it seems it is quite explicitly written for Plugin initialisation only. I am wondering if that means that there is no higher-level API that allows the registration.
I know that such features are available in Epsilon and Pivot OCL. Are these projects largely copying this code?
Given that dynamic load provides a lot of flexibility, it would be great if I could provide a succinct recipe for this.
|
|
| |
| Re: API-level facility for dynamic models [message #1858020 is a reply to message #1858014] |
Sat, 11 March 2023 10:16  |
|
Yes, sorry, that was not what I meant.
I was looking for a way to register a URI/URL so that it is resolved and dynamically loaded to provide the EPackage. The extension point that I pointed to does this. So if you give the URL of an Ecore model on the internet, the resource set obtains that resource, selects the first content, deserialises it with the corresponding resource factory and then selects the first content, or the eObject the URI fragment points at, returning in as an ePackage.
Ecore and the ATL tools both have a context menu that allows this. They end up with registrations in the global registry that are Descriptors. That is they are lazily resolved in access.
If the code for the extension point were public and would not refer to the extension point attributes, this code could be called programatically to make a registration.
I wonder if there is another piece of code that is public and achieves this.
|
|
|
| Re: API-level facility for dynamic models [message #1858022 is a reply to message #1858020] |
Sat, 11 March 2023 13:19 |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
It's not clear what kind of programmatic thing you are trying to achieve, who would be implementing such a thing, who would (need to) see those things, and for what purpose that's needed. Model instances can already use an xsi:schemaLocation to indicate where to locate their defining model. Ecore does not have a context menu for registering models in the global package registry. The Sample Editor Editor does have a context menu for loading an Ecore model from an arbitrary location. The dynamic_package extension point is generally intended to load a model provided by (located within) an installed bundle, not to load a model from the internet, though it could do that too, but that would be a poor idea, requiring internet access to function, which is not always available, and it would perform poorly. I can't comment on what ATL does, for what purpose, and in what context. Anyone can implement EPackage.Descriptor to do whatever they want without need for the framework to provide that implementation...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: API-level facility for dynamic models [message #1858029 is a reply to message #1858022] |
Sun, 12 March 2023 04:47 |
|
|
Thanks for you response. Sorry, I meant Epsilon has a context menu that allows this. And your final sentence confirmed me assumption, which is that from your point of view there is no need for the framework to provide that implementation. I disagree, since, as I pointed out, this functionality is being re-implemented in multiple locations and dynamic use of EMF is a common use case. But that is merely my point of view.
|
|
| |
| Re: API-level facility for dynamic models [message #1858042 is a reply to message #1858032] |
Sun, 12 March 2023 23:26 |
|
Sorry for being unclear. I will try to rephrase by describing the use case.
UC 1: As a modeller, I have an Ecore model stored in a project in the workbench. I would now like to add that model to the global ePackage registry of the eclipse runtime.
Solutions to this usecase have been provided in Epsilon and AM3 Tools through a context menu that creates a package descriptor in the global registry.
UC2: As an MDE toolchain user, I have an Ecore model stored in a resource that is accessible to a globally registered URIHandler (http, file, etc.) . I would now like to add that model to the global ePackage registry of the eclipse runtime.
Both Epsilon and AM3 provide means to load metamodels dynamically. However, these do not create package descriptor registrations in the global registry, but in the local registries associated with the tools sets.
UC3: As a tool developer, I would like to provide a facility to add an ECore model to the global ePackage registry of the eclipse runtime.
I find that a solution to this is offered by the org.eclipse.emf.ecore.dynamic_package extension point. It contains an implementation that reads the extension point attributes and adds or removes registrations. It also guards against colliding specifications. I find that this code is not API and that the functionality to add that model to the global ePackage registry is intertwined with the handling extension point attributes.
Note: I believe that API implementers are unlikely to look for this functionality because it is not API. But I believe making changes to the global ePackage registry is a common scenario. I cannot speak for Epsilon and AM3 or EMoflon or whereever I have seen copies of the 'register as metamodel' drop-down. Maybe all of these projects are happy to write their own. But given that they are building on a framework, I would guess that they enjoy common solutions provided by a framework.
At any rate, I guess I have my answer:
Quote:Anyone can implement EPackage.Descriptor to do whatever they want without need for the framework to provide that implementation...
|
|
|
| Re: API-level facility for dynamic models [message #1858046 is a reply to message #1858042] |
Mon, 13 March 2023 06:53 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
UC 1 is problematic at best. You have a model, you put it in the global registry, presumably to create instances anywhere and everywhere. But then you (can) change the model. Now you would want to replace what you registered? The existing instances are now broken, so what happens to them? It's just not clear how that's supposed to work. To me this behavior is a little like wanting to load a .class dynamically and then also being able to change it dynamically too; it's not generally workable...
UC 2 You can already do by creating a plugin that registers your model.
UC 3 You can already do by creating a plugin that registers your model.
Yes, UC2 and UC3 can be solved by creating a plugin and installing it. And for UC 1, there are good reasons why the global registry is populated the way that it is, i.e., via static, immutable, interconnected model instances.
All this still hasn't explained what exactly "API "you want. In any case, I hope that developers are generally not sorely tempted to mess with (mutate) the global registry, especially not in an IDE/Equinox application, but rather to work with the per-resource-set package registry so as to restrict their mutable (transient?) models to be available/visible only within their own context rather than being push out to be globally visible. The Ecore Editor and the GenModel infrastructure take that approach...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: API-level facility for dynamic models [message #1858047 is a reply to message #1858046] |
Mon, 13 March 2023 10:49 |
|
|
Thank you for your advice. I think this covers it. Effectively, the argument is that since the global ePackage registry's lifetime spans the system lifetime, it should effectively be immutable except at initialisation. This design is to prevent later changes to the registration causing corruption to models already referencing from within the system. Ultimately this is to ensure that clients within the systems are not exposed to unanticipated global changes.
|
|
| |
| Re: API-level facility for dynamic models [message #1858058 is a reply to message #1858049] |
Mon, 13 March 2023 23:54 |
|
Hi Ed,
Good advice, I will add that to my write-up. Just wanted to point out that the going practice does not seem to follow it, though. E.g. in Epsilon both the workflow function <epsilon.emf.register file="model/Entity.ecore" /> and the context menu directly overwrite registrations in the global ePackage registry, and not in a local one. You can see this effect by listing the registry after calling the function, or use the Epsilon view EMF EPackage Registry View. AM3 does the same. EMoflon is considering it and references the other implementations. I guess, in effect, this common practice led me to ask if there is a unifying API for this on the framework.
Best wishes,
JG
[Updated on: Mon, 13 March 2023 23:59] Report message to a moderator |
|
|
| Re: API-level facility for dynamic models [message #1858062 is a reply to message #1858058] |
Tue, 14 March 2023 07:29 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
EMF leaves things generally very wide open for abuse. There is very little of the implementation that is package/private versus public/protected such that pretty much everything can be specialized or abused. And some of such things are only abusive depending on the context where you used it. E.g., in a stand-alone application or a narrow application with a specific design intent, it's fine to use global registries as one sees fit and whatever is convenient. In an IDE application where dozens of technologies share the same global registries, and where there are well-define mechanisms for controlling what's in those registries via lazy/deferred registration mechanism, it's less okay. Of course most "other" applications won't care if there are additional packages registered in the global registry; after all, any additional plugin could be installed registering some additional packages. So I haven't seen or heard of any harmful effects from what these other folks are doing...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 03:54:33 GMT 2024
Powered by FUDForum. Page generated in 0.02472 seconds |
] 
Search
Help
Register
Login
Home
