[tigerstripe-dev] Bug 220345

[Eric Dillon <erdillon@xxxxxxxxx>]

Title: Bug 220345

Hi all,

Per bug 220345, I’ve just committed a number of changes to progress our use of EMF in the core.
I’ve extract the “model repository concept” (i.e. Allowing to assemble models in a classpath fashion rather than having explicit URIs to files in EMF files) from the Tigerstripe metamodel.
The idea is that each object in an EMF model need a unique name/ID globally so we can use that name instead of a URI reference in the saved files.

For example in the Tigerstripe metamodel, the unique name is the “fully qualified name” of a class (ie. Package+name).

Based on this assumption, I’ve extended the default save/load and reference resolution of EMF to use these names in files and to resolve. In other words, you can use a “model repository” within any Ecore as long as you provide a KeyProvider for each object (see example in org.eclipse.tigerstripe.repository.core.test based on regions, containing villages, made out of streets and houses :-)). The files will be saved with the standard XML EMF format using keys instead of URIs and upon load the lazy-resolution will look in the “classpath” of model to resolve the object based on a key/type if possible.

I’ve also reworked the Tigerstripe metamodel to use that (obviously) and now allow for basic read/write of our POJOs with the EMF repository framework. The POJO resources are in reasonable shape. It is only preliminary but seems to be shaping up nicely. 
In the Tigerstripe .ecore itself, I’ve removed the OSSJ-isms as discussed face2face. There needs to be more clean up but this constitute “progress” I’d say :-).

Note that none of these changes are actually used in the Workbench which will still rely on the old ArtifactManager until the new ModelManager (EMF repository based) is stable.

As a result of this I did a bit of refactoring internally. The following plugins were touched:
- org.eclipse.tigerstripe.test_common (Created)
- org.eclipse.tigerstripe.repository.core (Created)
- org.eclipse.tigerstripe.repository.core.test (Created)
- org.eclipse.tigerstripe.metamodel
- org.eclipse.tigerstripe.metamodel.test (Created)
- org.eclipse.tigerstripe.workbench.base
- org.eclipse.tigerstripe.workbench.base.test
- org.eclipse.tigerstripe.workbench.ui.base
- org.eclipse.tigerstripe.workbench.ui.instancediagram.diagram
- org.eclipse.tigerstripe.workbench.ui.UML2Import
- org.eclipse.tigerstripe.workbench.ui.visualeditor.adaptation
- org.eclipse.tigerstripe.workbench.ui.visualeditor.diagram

So you will need to run updates and get the newly created ones (the .test are not necessary if you don’t care about these specific Junit tests).

Eric