Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » different instances of ECorePackages
different instances of ECorePackages [message #426198] Thu, 18 December 2008 23:09 Go to next message
Joel Greenyer is currently offline Joel GreenyerFriend
Messages: 170
Registered: July 2009
Senior Member
Hi,
when I iterate over the references of an EClass, lets say PropertyCallExp (from ocl.ecore) that I obtain from the
..getEAllReferences() method, I observe that some references are typed over ECore classes from different ECorePackages,
see the example console output below`(I'm in the runtime workspace).
I have built a smarter IdemProvider for my editor that restricts the possible choices for some properties in the
properties view. This requires that I compare some things like the equality of EClasses - but here's a problem since
sometimes they are not equal instances. What can I do? Can I do something with the package registry...?

Thanks for helping.

Joel


Example Console output:

sourceNode.getType: org.eclipse.emf.ecore.impl.EClassImpl@1410c85 (name: PropertyCallExp) (instanceClassName: null)
(abstract: false, interface: false)
sourceNode.getType.getEPackage: org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
---
reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@1e2c656 (name: EAnnotation)
(instanceClassName: null) (abstract: false, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)

reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@be1a11 (name: EClassifier)
(instanceClassName: null) (abstract: true, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)

reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@b8c068 (name: EGenericType)
(instanceClassName: null) (abstract: false, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)

reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
(instanceClassName: null) (abstract: true, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions) (nsURI:
http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix: ocl.expr)

reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
(instanceClassName: null) (abstract: true, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions) (nsURI:
http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix: ocl.expr)

reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
(instanceClassName: null) (abstract: false, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore) (nsURI:
http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)

reference.getEType(): org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
(instanceClassName: null) (abstract: false, interface: false)
reference.getEType().getEPackage(): org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore) (nsURI:
http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
Re: different instances of ECorePackages [message #426199 is a reply to message #426198] Fri, 19 December 2008 00:12 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Joel,

I'm afraid I don't understand what the question is. All of the packages
in the EPackage.Registry have a unique identity. This is in the Java
sense and also in the namespace (identified by URI) sense.

Is your item provider trying to distinguish Ecore model elements by
name? It should be able just to use Java object identity for this purpose.

Cheers,

Christian


Joel Greenyer wrote:
> Hi,
> when I iterate over the references of an EClass, lets say
> PropertyCallExp (from ocl.ecore) that I obtain from the
> .getEAllReferences() method, I observe that some references are typed
> over ECore classes from different ECorePackages, see the example console
> output below`(I'm in the runtime workspace).
> I have built a smarter IdemProvider for my editor that restricts the
> possible choices for some properties in the properties view. This
> requires that I compare some things like the equality of EClasses - but
> here's a problem since sometimes they are not equal instances. What can
> I do? Can I do something with the package registry...?
>
> Thanks for helping.
>
> Joel
>
>
> Example Console output:
>
> sourceNode.getType: org.eclipse.emf.ecore.impl.EClassImpl@1410c85
> (name: PropertyCallExp) (instanceClassName: null) (abstract: false,
> interface: false)
> sourceNode.getType.getEPackage:
> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
> http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
> ---
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@1e2c656 (name: EAnnotation)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@be1a11 (name: EClassifier)
> (instanceClassName: null) (abstract: true, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@b8c068 (name: EGenericType)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
> (instanceClassName: null) (abstract: true, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
> ocl.expr)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
> (instanceClassName: null) (abstract: true, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
> ocl.expr)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
Re: different instances of ECorePackages [message #426200 is a reply to message #426198] Fri, 19 December 2008 00:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30886
Registered: July 2009
Senior Member
Joel,

Comments below.

Joel Greenyer wrote:
> Hi,
> when I iterate over the references of an EClass, lets say
> PropertyCallExp (from ocl.ecore) that I obtain from the
> .getEAllReferences() method, I observe that some references are typed
> over ECore classes from different ECorePackages, see the example
> console output below`(I'm in the runtime workspace).
Definitely the type of a feature can be in another package.
> I have built a smarter IdemProvider for my editor that restricts the
> possible choices for some properties in the properties view. This
> requires that I compare some things like the equality of EClasses -
> but here's a problem since sometimes they are not equal instances.
Different EClass instances that are not == will definitely not be .equals!
> What can I do? Can I do something with the package registry...?
You've provided very little context to explain why you might have
different instances of the "same" EClass.

There's a difference between something like the loaded Ecore model in
platform:/plugins/org.eclipse.emf.ecore/model/Ecore.ecore and the
generated EcorePackage.eINSTANCE. But without explaining what your
doing and how you arrived at where you are, I don't know what direction
to steer you...
>
> Thanks for helping.
>
> Joel
>
>
> Example Console output:
>
> sourceNode.getType: org.eclipse.emf.ecore.impl.EClassImpl@1410c85
> (name: PropertyCallExp) (instanceClassName: null) (abstract: false,
> interface: false)
> sourceNode.getType.getEPackage:
> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
> http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
> ---
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@1e2c656 (name: EAnnotation)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@be1a11 (name: EClassifier)
> (instanceClassName: null) (abstract: true, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@b8c068 (name: EGenericType)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
> (instanceClassName: null) (abstract: true, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
> ocl.expr)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
> (instanceClassName: null) (abstract: true, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
> ocl.expr)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> reference.getEType():
> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
> (instanceClassName: null) (abstract: false, interface: false)
> reference.getEType().getEPackage():
> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
Re: different instances of ECorePackages [message #426205 is a reply to message #426200] Fri, 19 December 2008 09:38 Go to previous messageGo to next message
Joel Greenyer is currently offline Joel GreenyerFriend
Messages: 170
Registered: July 2009
Senior Member
Hi Christian,
hi Ed,

I have an editor for "object patterns" -- that is there are nodes and edges representing objects and links (=instances
of EReference). An edge can therefore have a type EReference, which the user can set in the properties view. In order
not to show all EReferences in the drop-down list, but only those which can exist between source and target nodes (which
are typed over EClasses), I do the following in my EdgeItemProvider:

....
Node sourceNode = ((Edge)object).getSourceNode();
Node targetNode = ((Edge)object).getTargetNode();

Iterator sourceNodesClassOutgoingReferencesIterator =
((EClass)sourceNode.getType()).getEAllReferences().iterator( );
while (sourceNodesClassOutgoingReferencesIterator.hasNext()) {
EReference reference = (EReference) sourceNodesClassOutgoingReferencesIterator.next();

if (reference.getEType().equals(targetNode.getType())
|| ((EClass)targetNode.getType()).getEAllSuperTypes().contains( reference.getEType())){
choiceValueList.add(reference);
}

....

99% percent of the time this works fine. But, I recently tried to describe the abstract syntax of an OCL expression with
my nodes and edges. Then I saw that (in my runtime ws) that the type EClass of the EReference that should be equal to
the type EClass of the target node (or superclass thereof) isn't equal. <=== So that's my real problem ;) <===

On a closer look I found odd that the type EClass of PropertyCallExp.eType is of the package
org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI: http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix:
ocl.ecore)
but that the type EClass of PropertyCallExp.referredProperty is of the package
org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore) (nsURI: http://www.eclipse.org/emf/2002/Ecore,
nsPrefix: ecore)

Any idea why this happens?

I often had similar problems when working in the runtime workspace, but I learned to take very good care that all the
ecore models I reference from the models that I edit are also loaded from the runtime workspace. But now, there is
something referencing the generated EcorePackage from my workspace -- I don't know what to do.

Thanks for helping.

Joel


Ed Merks wrote:
> Joel,
>
> Comments below.
>
> Joel Greenyer wrote:
>> Hi,
>> when I iterate over the references of an EClass, lets say
>> PropertyCallExp (from ocl.ecore) that I obtain from the
>> .getEAllReferences() method, I observe that some references are typed
>> over ECore classes from different ECorePackages, see the example
>> console output below`(I'm in the runtime workspace).
> Definitely the type of a feature can be in another package.
>> I have built a smarter IdemProvider for my editor that restricts the
>> possible choices for some properties in the properties view. This
>> requires that I compare some things like the equality of EClasses -
>> but here's a problem since sometimes they are not equal instances.
> Different EClass instances that are not == will definitely not be .equals!
>> What can I do? Can I do something with the package registry...?
> You've provided very little context to explain why you might have
> different instances of the "same" EClass.
>
> There's a difference between something like the loaded Ecore model in
> platform:/plugins/org.eclipse.emf.ecore/model/Ecore.ecore and the
> generated EcorePackage.eINSTANCE. But without explaining what your
> doing and how you arrived at where you are, I don't know what direction
> to steer you...
>>
>> Thanks for helping.
>>
>> Joel
>>
>>
>> Example Console output:
>>
>> sourceNode.getType: org.eclipse.emf.ecore.impl.EClassImpl@1410c85
>> (name: PropertyCallExp) (instanceClassName: null) (abstract: false,
>> interface: false)
>> sourceNode.getType.getEPackage:
>> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
>> http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
>> ---
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@1e2c656 (name: EAnnotation)
>> (instanceClassName: null) (abstract: false, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@be1a11 (name: EClassifier)
>> (instanceClassName: null) (abstract: true, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@b8c068 (name: EGenericType)
>> (instanceClassName: null) (abstract: false, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
>> (instanceClassName: null) (abstract: true, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
>> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
>> ocl.expr)
>>
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
>> (instanceClassName: null) (abstract: true, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
>> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
>> ocl.expr)
>>
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
>> (instanceClassName: null) (abstract: false, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
>> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>
>> reference.getEType():
>> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
>> (instanceClassName: null) (abstract: false, interface: false)
>> reference.getEType().getEPackage():
>> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
>> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
Re: different instances of ECorePackages [message #426208 is a reply to message #426205] Fri, 19 December 2008 13:12 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30886
Registered: July 2009
Senior Member
Joel,

Comments below.

Joel Greenyer wrote:
> Hi Christian,
> hi Ed,
>
> I have an editor for "object patterns" -- that is there are nodes and
> edges representing objects and links (=instances of EReference). An
> edge can therefore have a type EReference, which the user can set in
> the properties view. In order not to show all EReferences in the
> drop-down list, but only those which can exist between source and
> target nodes (which are typed over EClasses), I do the following in
> my EdgeItemProvider:
>
> ...
> Node sourceNode = ((Edge)object).getSourceNode();
> Node targetNode = ((Edge)object).getTargetNode();
>
> Iterator sourceNodesClassOutgoingReferencesIterator =
> ((EClass)sourceNode.getType()).getEAllReferences().iterator( );
> while (sourceNodesClassOutgoingReferencesIterator.hasNext()) {
> EReference reference = (EReference)
> sourceNodesClassOutgoingReferencesIterator.next();
>
> if (reference.getEType().equals(targetNode.getType())
> ||
> ((EClass)targetNode.getType()).getEAllSuperTypes().contains( reference.getEType())){
>
Consider using getEReferenceType instead of casting getEType(), and
using EClass.isSuperTypeOf. Calling methods like getEType in a loop
when the value is the same for each iteration isn't great...
> choiceValueList.add(reference);
> }
>
> ...
>
> 99% percent of the time this works fine. But, I recently tried to
> describe the abstract syntax of an OCL expression with my nodes and
> edges. Then I saw that (in my runtime ws) that the type EClass of the
> EReference that should be equal to the type EClass of the target node
> (or superclass thereof) isn't equal. <=== So that's my real problem ;)
> <===
>
> On a closer look I found odd that the type EClass of
> PropertyCallExp.eType is of the package
> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
> http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
This looks like the development time version of the OCL model (loaded
from the models folder) rather than the generated version of the package
for that.
> but that the type EClass of PropertyCallExp.referredProperty is of the
> package
> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>
> Any idea why this happens?
How did you get a hold of the model/EPackage for OCL?
>
> I often had similar problems when working in the runtime workspace,
> but I learned to take very good care that all the ecore models I
> reference from the models that I edit are also loaded from the runtime
> workspace. But now, there is something referencing the generated
> EcorePackage from my workspace -- I don't know what to do.
You'll be able to tell the ones that refer to Ecore via its nsURI,
http://www.eclipse.org/emf/2002/Ecore, verses ones that references the
development time version using
platform:/resource/org.eclispe.emf.ecore/model/Ecore.ecore or
platform:/plugin/org.eclispe.emf.ecore/model/Ecore.ecore. It's quite
common for models to use the former directly...

You can use URI mappings in the resource set's URI converter or
registrations in the resource set's package registry to redirect which
instances is used during loaded... I still don't completely understand
the context...
>
> Thanks for helping.
>
> Joel
>
>
> Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>> Joel Greenyer wrote:
>>> Hi,
>>> when I iterate over the references of an EClass, lets say
>>> PropertyCallExp (from ocl.ecore) that I obtain from the
>>> .getEAllReferences() method, I observe that some references are
>>> typed over ECore classes from different ECorePackages, see the
>>> example console output below`(I'm in the runtime workspace).
>> Definitely the type of a feature can be in another package.
>>> I have built a smarter IdemProvider for my editor that restricts the
>>> possible choices for some properties in the properties view. This
>>> requires that I compare some things like the equality of EClasses -
>>> but here's a problem since sometimes they are not equal instances.
>> Different EClass instances that are not == will definitely not be
>> .equals!
>>> What can I do? Can I do something with the package registry...?
>> You've provided very little context to explain why you might have
>> different instances of the "same" EClass.
>>
>> There's a difference between something like the loaded Ecore model in
>> platform:/plugins/org.eclipse.emf.ecore/model/Ecore.ecore and the
>> generated EcorePackage.eINSTANCE. But without explaining what your
>> doing and how you arrived at where you are, I don't know what
>> direction to steer you...
>>>
>>> Thanks for helping.
>>>
>>> Joel
>>>
>>>
>>> Example Console output:
>>>
>>> sourceNode.getType: org.eclipse.emf.ecore.impl.EClassImpl@1410c85
>>> (name: PropertyCallExp) (instanceClassName: null) (abstract: false,
>>> interface: false)
>>> sourceNode.getType.getEPackage:
>>> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore)
>>> (nsURI: http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
>>> ---
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@1e2c656 (name: EAnnotation)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@be1a11 (name: EClassifier)
>>> (instanceClassName: null) (abstract: true, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@b8c068 (name: EGenericType)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
>>> (instanceClassName: null) (abstract: true, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
>>> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
>>> ocl.expr)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
>>> (instanceClassName: null) (abstract: true, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
>>> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
>>> ocl.expr)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
>>> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
>>> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
Re: different instances of ECorePackages [message #426209 is a reply to message #426205] Fri, 19 December 2008 13:30 Go to previous message
Eclipse UserFriend
Originally posted by: cdamus.zeligsoft.com

Hi, Joel,

See some replies in-line, below.

HTH,

Christian

Joel Greenyer wrote:
> Hi Christian,
> hi Ed,
>
> I have an editor for "object patterns" -- that is there are nodes and
> edges representing objects and links (=instances of EReference). An edge
> can therefore have a type EReference, which the user can set in the
> properties view. In order not to show all EReferences in the drop-down
> list, but only those which can exist between source and target nodes
> (which are typed over EClasses), I do the following in my
> EdgeItemProvider:
>
> ...
> Node sourceNode = ((Edge)object).getSourceNode();
> Node targetNode = ((Edge)object).getTargetNode();
>
> Iterator sourceNodesClassOutgoingReferencesIterator =
> ((EClass)sourceNode.getType()).getEAllReferences().iterator( );
> while (sourceNodesClassOutgoingReferencesIterator.hasNext()) {
> EReference reference = (EReference)
> sourceNodesClassOutgoingReferencesIterator.next();
>
> if (reference.getEType().equals(targetNode.getType())
> ||
> ((EClass)targetNode.getType()).getEAllSuperTypes().contains( reference.getEType())){
>
> choiceValueList.add(reference);
> }
>
> ...

You could do reference.getEType().isSuperTypeOf(targetNode.getType()),
but that's an unrelated matter. :-)


> 99% percent of the time this works fine. But, I recently tried to
> describe the abstract syntax of an OCL expression with my nodes and
> edges. Then I saw that (in my runtime ws) that the type EClass of the
> EReference that should be equal to the type EClass of the target node
> (or superclass thereof) isn't equal. <=== So that's my real problem ;) <===
>
> On a closer look I found odd that the type EClass of
> PropertyCallExp.eType is of the package
> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
> http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)

The eType of a PropertyCallExp is of type ecore::EClassifier, which is
not defined in the ocl.ecore package. However, the *value* of the
PropertyCallExp::eType for your particular call expression may be the
EClass eclassifier from the ecore package.


> but that the type EClass of PropertyCallExp.referredProperty is of the
> package
> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)

The type of the PropertyCallExp::referredProperty reference is
EStructuralFeature, not EClass. The *value* of this property in your
call expression presumably is some ereference from the ecore package,
given that the call expression's type is the EClass eclass.


> Any idea why this happens?

I think what's happening is that your application is getting confused by
the circular nature of Ecore. The OCL Abstract Syntax extends Ecore and
is, therefore, a metamodel in this context, not a model. So, you have
to be careful hov you treat instances of it and their references to
Ecore elements such as EClass and EStructural feature. They are at one
meta-level higher than model instances like Library.

Sometimes EClass is a metaclass and sometimes it's a class. Your item
provider will have to know which interpretation to make


> I often had similar problems when working in the runtime workspace, but
> I learned to take very good care that all the ecore models I reference
> from the models that I edit are also loaded from the runtime workspace.
> But now, there is something referencing the generated EcorePackage from
> my workspace -- I don't know what to do.
>
> Thanks for helping.
>
> Joel
>
>
> Ed Merks wrote:
>> Joel,
>>
>> Comments below.
>>
>> Joel Greenyer wrote:
>>> Hi,
>>> when I iterate over the references of an EClass, lets say
>>> PropertyCallExp (from ocl.ecore) that I obtain from the
>>> .getEAllReferences() method, I observe that some references are typed
>>> over ECore classes from different ECorePackages, see the example
>>> console output below`(I'm in the runtime workspace).
>> Definitely the type of a feature can be in another package.
>>> I have built a smarter IdemProvider for my editor that restricts the
>>> possible choices for some properties in the properties view. This
>>> requires that I compare some things like the equality of EClasses -
>>> but here's a problem since sometimes they are not equal instances.
>> Different EClass instances that are not == will definitely not be
>> .equals!
>>> What can I do? Can I do something with the package registry...?
>> You've provided very little context to explain why you might have
>> different instances of the "same" EClass.
>>
>> There's a difference between something like the loaded Ecore model in
>> platform:/plugins/org.eclipse.emf.ecore/model/Ecore.ecore and the
>> generated EcorePackage.eINSTANCE. But without explaining what your
>> doing and how you arrived at where you are, I don't know what
>> direction to steer you...
>>>
>>> Thanks for helping.
>>>
>>> Joel
>>>
>>>
>>> Example Console output:
>>>
>>> sourceNode.getType: org.eclipse.emf.ecore.impl.EClassImpl@1410c85
>>> (name: PropertyCallExp) (instanceClassName: null) (abstract: false,
>>> interface: false)
>>> sourceNode.getType.getEPackage:
>>> org.eclipse.emf.ecore.impl.EPackageImpl@10a0018 (name: ecore) (nsURI:
>>> http://www.eclipse.org/ocl/1.1.0/Ecore, nsPrefix: ocl.ecore)
>>> ---
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@1e2c656 (name: EAnnotation)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@be1a11 (name: EClassifier)
>>> (instanceClassName: null) (abstract: true, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@b8c068 (name: EGenericType)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@bdd7f (name: ecore) (nsURI:
>>> http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
>>> (instanceClassName: null) (abstract: true, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
>>> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
>>> ocl.expr)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@172c80f (name: OCLExpression)
>>> (instanceClassName: null) (abstract: true, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EPackageImpl@6cfce (name: expressions)
>>> (nsURI: http://www.eclipse.org/ocl/1.1.0/OCL/Expressions, nsPrefix:
>>> ocl.expr)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
>>> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
>>>
>>> reference.getEType():
>>> org.eclipse.emf.ecore.impl.EClassImpl@6076c4 (name: EObject)
>>> (instanceClassName: null) (abstract: false, interface: false)
>>> reference.getEType().getEPackage():
>>> org.eclipse.emf.ecore.impl.EcorePackageImpl@11ef9f6 (name: ecore)
>>> (nsURI: http://www.eclipse.org/emf/2002/Ecore, nsPrefix: ecore)
Previous Topic:xsi:nil attribute not loaded in AnyType when resource is loaded
Next Topic:Add IProgressMonitor to DeleteCommand
Goto Forum:
  


Current Time: Thu Feb 20 04:05:05 GMT 2020

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

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

Back to the top