Eclipse Community Forums: EMF » Split Ecore model over different repos

Help

Home

Home » Modeling » EMF » Split Ecore model over different repos(Relative paths in the Ecore model get broken)

Show: Today's Messages :: Show Polls :: Message Navigator

Split Ecore model over different repos [message #1828761]

Thu, 18 June 2020 07:58

Cees Bos

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.

Report message to a moderator

Re: Split Ecore model over different repos [message #1828788 is a reply to message #1828761]

Thu, 18 June 2020 14:40

Ed Merks

Messages: 33264
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/

Report message to a moderator

Previous Topic:	TableViewer of EMF object with calculated column?
Next Topic:	Programatically edit XML Schema file

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Dec 26 20:53:56 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter