Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Split Ecore model over different repos(Relative paths in the Ecore model get broken)
Split Ecore model over different repos [message #1828761] Thu, 18 June 2020 07:58 Go to next message
Cees Bos is currently offline Cees BosFriend
Messages: 1
Registered: June 2020
Junior Member
We have a common class model defined in an Ecore model.
From derived Ecore models we want to reuse classes from the common model.
And probably we will have links between derived ecore models.

While working an a PoC we have it now in 1 git repos, but different Maven modules.
That is working 'fine', but we have relative references in the Ecore model:

 <eClassifiers xsi:type="ecore:EClass" name="TypeDefinition" eSuperTypes="../../../../common-data-model//src/main/resources/common.ecore#//LCClass">


  <eClassifiers xsi:type="ecore:EClass" name="Event">
    <eStructuralFeatures xsi:type="ecore:EReference" name="operations" upperBound="-1"
        eType="ecore:EClass ../../../../common-data-model/src/main/resources/common.ecore#//Operation"/>
  </eClassifiers>


We like to split this in different Git repositories, so teams can work independently on their derived models without bothering others.
The number of derived models will grow and the teams are geographically spread.

Is there a way we can create the references differently then relative paths or absolute paths? Absolute paths require that the folder structure is on developer machines and CI servers is always the same.
Re: Split Ecore model over different repos [message #1828788 is a reply to message #1828761] Thu, 18 June 2020 14:40 Go to previous message
Ed Merks is currently online Ed MerksFriend
Messages: 31827
Registered: July 2009
Senior Member
Firstly, don't put your Ecore model in a src folder. Why? Because where it's located at development time and where is located in a binary plugin will be different making it impossible to have a single consistent way of referencing the resource. Also, your approach doesn't allow you to provide a consistent relative location for the *.ecore's corresponding *.genmodel. For example Ecore.ecore is registered like this:

https://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore/plugin.xml#n49

That's not possible if we put the model in a source folder so sometimes it's under src/..., bin/..., and eventually just in <jar>!/...

Then look, for example of how Change.ecore references Ecore.ecore:

https://git.eclipse.org/c/emf/org.eclipse.emf.git/tree/plugins/org.eclipse.emf.ecore.change/model/Change.ecore

The essential underlying point is that org.eclipse.emf.ecore.plugin.EcorePlugin.computePlatformURIMap(boolean) will make *.ecore models in the target platform (binary plugins) look as if they are logically available as projects in the workspace so that, logically, platform:/resource/... can be used to reference the *.ecore model whether it's actually in the workspace or not.




Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:TableViewer of EMF object with calculated column?
Next Topic:Programatically edit XML Schema file
Goto Forum:
  


Current Time: Mon Apr 12 13:51:56 GMT 2021

Powered by FUDForum. Page generated in 0.05204 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top