URI Handling during Metamodel Creation and Reuse

[NeumannDirk]

TL;DR: Questions on URI handling in Ecore: controlling relative paths, using nsUri instead of file paths, and cleaner aliases.

Hello,
I am not completely new to EMF, but recently I encountered multiple problems for which I hope I can find some answers here. I plan to split them into multiple parts, each addressing a specific issue. They will share the same topic of reusing metamodels in other metamodels, and I also created an example project, which can be found here. I will keep it there and add possible answers to it in case somebody will have similar issues.

This is the first of my issues, addressing the URI handling during metamodel creation and reuse.

I have the following setup: I have a metamodel, in this case the book-metamodel book.ecore. I want to create a second metamodel, the library metamodel, from code. Since it is generated and reuses the book metamodel, I call it the gen_libraryWithBooksAsLoadedResource.ecore.

The code is in MetamodelCreator. It will load the book metamodel and register its package and also the ecore-metamodel and will then create and save the new metamodel. However, the reference to the book metamodel differs by one "../" (compare with hand-modeled libraryWithBooksAsLoadedResource.ecore when created via the UI). I understand that this is because the current directory during execution is the project folder and not the model folder. So, here are the questions:

1. Relative Paths

Can I influence this by somehow setting a target folder? Like pathToBookEcore="disc/resource/models/book.ecore" and targetpath="disc/myprojects/generator/model/gen_libraryWithBooksAsLoadedResource.ecore" and then the relative path is set in the metamodel independent of the current working directory, in this case to: ../../../resource/models/book.ecore? I know that there is the URIHandler, but I do not know if, and if so, how to use it in this process.

2. Using nsUri instead of file paths

Can I set an option to use the nsUri of the book metamodel package instead of the relative file path, like so:
eType="ecore:EClass http://www.kit.tva.metamodels/book#//Book"
I load and register the packages manually anyway, so this seems cleaner.

3. Aliases for readability

If I have many references to Book, can I use an alias in the header of the metamodel, e.g.:
xmlns:book="http://www.kit.tva.metamodels/book"
<[...] eType="ecore:EClass book:Book"/>
instead of
<[...] eType="ecore:EClass http://www.kit.tva.metamodels/book#//Book"/>
For metamodels with hundreds of classes this is cleaner, and it is the standard for ecore-types already.

I hope I explained the issue clearly. Thanks a lot for any help!
If these features do not exist yet, I’d also be happy to help with implementing them with some guidance.

Best regards,
Dirk

[merks]

When it comes to relative URIs, always load every resource with an absolute URI. If you have a File, using File.getAbsolutePath before creating a URI from it. The relative paths are exactly like you would expect and get if these were HTML pages. You can use org.eclipse.emf.ecore.xmi.impl.URIHandlerImpl or specialize it to specialize the behavior, but in the end, you need to produce something that something else can read.

You can also make use of org.eclipse.emf.ecore.resource.URIConverter.getURIMap() to load a resource via a logical URI that's remapped to another location (physical location). E.g., you might redirect a platform:/resource/project URI to a file:/<absolute-location-of-project> so that when the resources are later available as projects in the workspace, the URIs will work the same way.

Using the nsURI to reference a model will look for the reosurce in the EPacakge.Registry.INSTANCE, i.e., it will assume it's generated and installed in the runtime.

No, you cannot use a QName as a URI with the hope that prefix:Name will expanded a URI. Don't mix up metamodel references, ecore:EClass which refers to a registered model in the runtime versus an instance reference which must be a full URI, (and of course it's easy to confuse the two when the instance is also an Ecore model, but it's still not the same).

If you expect any other tools to read these *.ecore models, they will need to follow the existing conventions.