Home » Modeling » EMF » reference ecore model path of a different ecore model
| |
| Re: reference ecore model path of a different ecore model [message #1718837 is a reply to message #1718287] |
Wed, 30 December 2015 22:35   |
 Rafhael Cunha
Messages: 19
Registered: November 2015 |
Junior Member |
|
|
Ed, thanks for your response.
In fact today I have more notion that doubt is related to EMF. At least the initial part. What do I need to do is use resources (entities) of a ecore in another ecore. What I do is reload the ecore1 in ecore2 to view the entities present in the right ecore1?
Let me give an example, I have two ecores, mybase.ecore and mybase2.ecore
MyBase the code is this:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Mybase" nsURI="URI.createPlatformResourceURI()" nsPrefix="teste-22-12-2015">
<eClassifiers xsi:type="ecore:EClass" name="NodeQuadrado">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="label" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
iD="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Domain">
<eStructuralFeatures xsi:type="ecore:EReference" name="nodeQuadrados" upperBound="-1"
eType="#//NodeQuadrado" containment="true"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="nodeCirculos" upperBound="-1"
eType="#//NodeCirculo" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="NodeCirculo">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="label" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
</eClassifiers>
</ecore:EPackage>
and the mybase2 is this:
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Mybase2" nsURI="URI.createPlatformResourceURI()" nsPrefix="teste-22-12-2015">
<eClassifiers xsi:type="ecore:EClass" name="NodeQuadrado" eSuperTypes="Mybase.ecore#//NodeQuadrado"/>
</ecore:EPackage>
What I do is the mybase2 in nodequadrado references the nodequadrado the mybase1. To this end, the mybase2ecore I loaded the MyBase resource and put the super type of nodequadrado mybase2 was nodequadrado the mybase1. It is true?
I do not know how to do is put a unique ID to each element as you suggested, due to the need of the instances are not always loaded together. How do I do that?
Regarding URI.createPlatformResourceURI () method, I'm putting it on the field in nsURI own IDE when I edit the Ecore. It is true?
In other responses from users GMF forum, dizeram me should I put this URI.createPlatformResourceURI method for the file (resource) is in a dynamic way and enables portability of the model. Is this really true? If so, where should I put this method? It is at some particular file or in the properties tab in ns URI field?
I also talked to by my diagrams are not loaded all together, I put a unique identifier on each element of my diagram. For ecore can recognize that even open another place, it is that entity. For that suggested me use guids. Have you heard? How should I use it?
|
|
|
| Re: reference ecore model path of a different ecore model [message #1718851 is a reply to message #1718837] |
Thu, 31 December 2015 07:09 |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Rafhael,
Comments below.
On 30/12/2015 11:35 PM, Rafhael Cunha wrote:
> Ed, thanks for your response.
>
> In fact today I have more notion that doubt is related to EMF. At
> least the initial part. What do I need to do is use resources
> (entities) of a ecore in another ecore. What I do is reload the ecore1
> in ecore2 to view the entities present in the right ecore1?
>
> Let me give an example, I have two ecores, mybase.ecore and mybase2.ecore
>
> MyBase the code is this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Mybase"
> nsURI="URI.createPlatformResourceURI()" nsPrefix="teste-22-12-2015">
> <eClassifiers xsi:type="ecore:EClass" name="NodeQuadrado">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="label"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"
> iD="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="Domain">
> <eStructuralFeatures xsi:type="ecore:EReference" name="nodeQuadrados"
> upperBound="-1"
> eType="#//NodeQuadrado" containment="true"/>
> <eStructuralFeatures xsi:type="ecore:EReference" name="nodeCirculos"
> upperBound="-1"
> eType="#//NodeCirculo" containment="true"/>
> </eClassifiers>
> <eClassifiers xsi:type="ecore:EClass" name="NodeCirculo">
> <eStructuralFeatures xsi:type="ecore:EAttribute" name="label"
> eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/>
> </eClassifiers>
> </ecore:EPackage>
>
> and the mybase2 is this:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="Mybase2"
> nsURI="URI.createPlatformResourceURI()" nsPrefix="teste-22-12-2015">
> <eClassifiers xsi:type="ecore:EClass" name="NodeQuadrado"
> eSuperTypes="Mybase.ecore#//NodeQuadrado"/>
> </ecore:EPackage>
>
>
> What I do is the mybase2 in nodequadrado references the nodequadrado
> the mybase1. To this end, the mybase2ecore I loaded the MyBase
> resource and put the super type of nodequadrado mybase2 was
> nodequadrado the mybase1. It is true?
Yes, and from the relative path I would assume they appear to be in the
same folder.
>
> I do not know how to do is put a unique ID to each element as you
> suggested, due to the need of the instances are not always loaded
> together. How do I do that?
Ecore resource's don't use ID-based references. They always use
fragment path style references.
>
>
> Regarding URI.createPlatformResourceURI () method, I'm putting it on
> the field in nsURI own IDE when I edit the Ecore. It is true?
No, the nsURI should be a logical URI, and best it be an absolute URI,
i.e., one with a scheme. It need not resolve to anything. Also, each
EPackage should have a different nsURI and should be different from the
nsURI of any other package that might ever be installed in the same IDE
as your EPackages.
>
>
> In other responses from users GMF forum, dizeram me should I put this
> URI.createPlatformResourceURI method for the file (resource) is in a
> dynamic way and enables portability of the model. Is this really true?
When writing Java code that loads resources from the workspace (whether
they contain Ecore instances or other model instance), yes you should
use URI.createPlatformResourceURI to specify the absolute URI used to
load the resource. But this has nothing to do with the nsURI of your
package.
> If so, where should I put this method?
Are you loading resource programmatically yourself?
> It is at some particular file or in the properties tab in ns URI field?
It's related to what URI you use the load resources programmatically.
You'll see in the generated editors, including the Sample Ecore Editor,
the URI of each resource. So in your example above with the Sample Ecore
Editor, you'll see both resources of the resource set and the URIs will
both be of the form
platform:/resource/<project>/<path>/<file-name>.ecore. When each
resource is saved, EMF will try as much as possible to serialize
relative URIs. If all the URIs in the resource set are of the form
platform:/resource/... then all the references can and will be made
relative. As such, if all the projects in your workspace were actually
in the file system, all projects in some common root folder, you could
load any them using a file:/... URI and all the relative references
would resolve properly. That's the point about making them "portable".
As long as all references are relative, you can move all the resources
to any other location and all would resolve properly at that location,
i.e., because no reference specifies the absolute location of another
resource, no resource must be absolutely located at any particular place.
If you've ever written HTML, you'll realize you've been doing the same
thing whenever your specified a link, i.e., an href. If the reference
is to something you're authoring that will be hosted on the same
website, you use a relative reference, otherwise you'd have hard time
authoring and testing the links while the resources are still local to
your own physical machine before your publish it to a website.
>
> I also talked to by my diagrams are not loaded all together, I put a
> unique identifier on each element of my diagram.
Yes, but that has nothing to do with how your Ecore model itself is
serialized.
> For ecore can recognize that even open another place, it is that
> entity. For that suggested me use guids. Have you heard? How should I
> use it?
This is an issue related to your model instances. A reference to an
EObject if always a URI that consists of two parts
<resource-uri>#<eobject-fragment>. The first part of the URI relates to
how the resource is located, and what type of resource implementation is
created. The second part, the fragment, is related to how the EObject
is located within that resource. The resource URI should generally be
an absolute hierarchical URI, i.e., of the form <scheme>:/..., this
ensures that serialized reference will generally be relative when
possible, making the resources themselves relatively relocatable, i.e.,
portable. EMF supports two types of fragment, path-based and ID-based,
where the IDs can either be intrinsic or extrinsic. The fragment-based
paths are the easiest to manage, but they are fragile with respect to
the stability of the reference when the instance is changed, i.e., when
the EObject is moved to a different path within the resource.
EcoreResourceImpl uses fragment-based paths, and addresses the stability
issue by specializing in the model the segments used within the path,
i.e., in
org.eclipse.emf.ecore.impl.EModelElementImpl.eURIFragmentSegment(EStructuralFeature,
EObject) and
org.eclipse.emf.ecore.impl.EModelElementImpl.eObjectForURIFragmentSegment(String)
the Ecore model implementation specializes how the segments are produced
and traversed. Also, on your containment reference of your own model,
you can, specify the eKeys of that reference to influence how the
segment of the path looks: by default it's of the form
@<feature-name>{.<index-in-feature>], so fragment segments within a
multi-valued reference will be positionally based, which is clearly
highly unstable with respect to moving an EObject within it's containing
list. With an eKey specified, the reference will be of the form
@<feature-name>[<key1>='<value1>'{,<key2>='value2'}*]. In this case, the
contained EObject's must have one or more attributes that uniquely
identify the containing object within that list. For example, the
EClassifiers in EPackage.eClassifiers must have unique names, so the
EClassifier.name is a key; but support for eKeys was added later, so
Ecore doesn't use that, but has specialized the methods I mentioned
above so that instead of using @eClassifiers[name='<classifier-name'],
it simply uses <classifier-name>; but to the same effect.
ID based references have the advantage of being highly stable, but come
at the cost of maintaining their uniqueness. An EAttribute can have
isID set to true in the model. The value of that feature, if specified
in the instance, must be unique within the containing resource. It's
hard to assign useful IDs and hard to maintain their uniqueness. These
are the so-called intrinsic IDs, because the model instances directly
contain the ID values. The so-called extrinsic IDs are maintained by
the resource implementation itself. XMLResourceImpl has support for
that, so if you define your own resource factory that created an
XMLResourceImpl or XMIResourceImpl that specializes the
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.useUUIDs() to return
true, the resource will automatically associate a UUID with each EObject
added to that resource and when serialized, that UUID will be serialized
along with the EObject, e.g., as xmi:ID, and when deserialized the map
will be loaded so that the EObjects can be looked up with that ID.
That's no doubt what the GMF folks were telling you would be best.
It's certainly the easiest to maintain. In your GenPackage (the child
of the root GenModel of a *.genmodel resource), you can specify the
Resource Type property to be XMI or XML and the generator will generate
a resource factory and resource implementation, and register them in the
plugin.xml. You can specialize that resource implementation to ensure
it uses UUIDs.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Wed Apr 24 21:03:19 GMT 2024
Powered by FUDForum. Page generated in 0.02972 seconds |
] 
Search
Help
Register
Login
Home
