Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] ClassCastException in save action and some diff meta model questions
| [EMF Compare] ClassCastException in save action and some diff meta model questions [message #134015] |
Mon, 16 March 2009 10:39  |
Eclipse User |
|
|
|
Dear developers,
I get a class cast exception if I try to execute my own save action (3.5M5):
java.lang.ClassCastException: org.eclipse.emf.compare.diff.metamodel.impl.ComparisonResour ceSetSnapshotImpl cannot be cast to org.eclipse.emf.compare.diff.metamodel.ComparisonResourceSna pshot
at org.eclipse.emf.compare.ui.export.ExportMenu$2.run(ExportMen u.java:255)
...
Seems to me like a bug?
Btw, is there any documentation why you changed the diff meta model from 3.4 to 3.5?
- introducing classes for changes in resources
- removing classes for changes (e.g. AddAttribute)
- renaming references (e.g. ReferenceChangeLeftTarget.leftRemoveTarget to .leftTarget)
Furthermore I wonder why all the subclasses have their own references to the models (e.g. leftTarget, rightTarget, leftElement, etc) instead of moving these references to a common superclass or interface?
Another thing: Does it make sense to have the reference DiffElement.subDiffElements for DiffElements? This means that for example AttributeChange can also have subDiffElements (which in my eyes does not make much sense?). I would rather expect it to be DiffGroup.subDiffElements (and maybe
UpdateModelElement.subDiffelements as well)?
Last question: How is the status about the "patch/changeset model"?
The reason I ask is because I am implementing something similar (details in technical report [1]) at the moment (as also mentioned in the post 'Infos about the planned "patch/changeset model" feature?' on 09-09-2008).
My status is that I am able to save a model-independent diff; the next step I am working on is to apply it to another model.
Best regards
Patrick
[1] http://orbit.dtu.dk/getResource?recordId=232303&objectId =1&versionId=1
|
|
| |
| Re: [EMF Compare] ClassCastException in save action and some diff meta model questions [message #134061 is a reply to message #134016] |
Tue, 17 March 2009 05:06  |
| Eclipse User |
|
|
|
Thank you Laurant, that was very informative.
Further comments below.
>> Btw, is there any documentation why you changed the diff meta model
>> from 3.4 to 3.5?
>> - introducing classes for changes in resources
>> - removing classes for changes (e.g. AddAttribute)
>> - renaming references (e.g. ReferenceChangeLeftTarget.leftRemoveTarget
>> to .leftTarget)
>>
>
> All of these changes have been made in an attempt to simplify the Diff
> metamodel and get rid of redundant code and classes. For exeample
> AddAttribute and RemoteRemoveAttribute were both "dummy" classes which
> only purpose was to provide a name for these changes. They have been
> removed and replaced by their common superclass
> "AttributeChangeLeftTarget". There is no real documentation on this API
> breakage apart from the Javadoc itself, but most of these changes are
> listed on https://bugs.eclipse.org/bugs/show_bug.cgi?id=233451 .
I totally agree that the API is much more concise now.
A little bit confusing to me, however, is the current naming. Since I do not consider three-way-compares, it sounds strange to use an AttributeChangeLeftTarget to describe a removed attribute.
But maybe I just need to get used to that ;-)
>> Furthermore I wonder why all the subclasses have their own references
>> to the models (e.g. leftTarget, rightTarget, leftElement, etc) instead
>> of moving these references to a common superclass or interface?
>>
>
> Some changes have links towards left elements, some towards right
> elements, some towards both ... Moving these references to superclasses
> would ruin the Diff Model readability (or so I think). I kept these
> references on the actual DiffElements for this reason alone. If you
> think there would be a better way to order these feel I'd like to hear
> your thoughts :) (though I fear it is too late now as M6 is nigh).
Then we probably have a different opinion about readability ;-) But this is fair enough.
My choice was to add one reference to the DiffElement pointing to the 'correspondingElement' of the source and target model, which is the element that was 'changed'.
The meaning of the correspondingElement differs for the concrete DiffElements:
Attribute changes - correspondingElement is pointing to the element containing the attribute
Reference changes - correspondingElement is pointing to the element containing the reference
Movement - correspondingElement is pointing to the moved element
Addition and deletion - correspondingElement is pointing to the parent element of the added/deleted element
This way, DiffElement.correspondingElement is always pointing to the changed element.
Of course we need more references for most concrete DiffElements..
>> Last question: How is the status about the "patch/changeset model"?
>> The reason I ask is because I am implementing something similar
>> (details in technical report [1]) at the moment (as also mentioned in
>> the post 'Infos about the planned "patch/changeset model" feature?' on
>> 09-09-2008).
>> My status is that I am able to save a model-independent diff; the next
>> step I am working on is to apply it to another model.
>>
>
> The EPatch has recently been committed on CVS HEAD, you can check the
> bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=262928 or the CQ
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3063 for more information.
Thanks, I'll give it a try :-)
Best regards
Patrick
|
|
| |
| Re: [EMF Compare] ClassCastException in save action and some diff meta model questions [message #134077 is a reply to message #134070] |
Wed, 18 March 2009 03:23 |
| Eclipse User |
|
|
|
Hi Laurent,
comments again inline.
>>>> Furthermore I wonder why all the subclasses have their own references
>>>> to the models (e.g. leftTarget, rightTarget, leftElement, etc) instead
>>>> of moving these references to a common superclass or interface?
>>>>
>>>
>>> Some changes have links towards left elements, some towards right
>>> elements, some towards both ... Moving these references to superclasses
>>> would ruin the Diff Model readability (or so I think). I kept these
>>> references on the actual DiffElements for this reason alone. If you
>>> think there would be a better way to order these feel I'd like to hear
>>> your thoughts :) (though I fear it is too late now as M6 is nigh).
>>
>> Then we probably have a different opinion about readability ;-) But
>> this is fair enough.
>> My choice was to add one reference to the DiffElement pointing to the
>> 'correspondingElement' of the source and target model, which is the
For clarification, what I implicitly meant:
DiffElement.correspondingLeftElement (to 'left' model)
DiffElement.correspondingRightElement (to 'right' model)
>> element that was 'changed'.
>> The meaning of the correspondingElement differs for the concrete
>> DiffElements:
>> Attribute changes - correspondingElement is pointing to the element
>> containing the attribute
>> Reference changes - correspondingElement is pointing to the element
>> containing the reference
>> Movement - correspondingElement is pointing to the moved element
>> Addition and deletion - correspondingElement is pointing to the parent
>> element of the added/deleted element
>>
>> This way, DiffElement.correspondingElement is always pointing to the
>> changed element.
>> Of course we need more references for most concrete DiffElements..
>>
>
> I don't think this could be done ... to take the exemple of reference
> changes, we have to keep references to :
> left element => the element from the left model containing a reference
> which value(s) changed
> right element => the element from the right model containing a reference
> which value(s) changed
> reference => the actual reference that's been changed
In this case leftElement could be correspondingLeftElement and rightElement correspondingRightElement.
The reference, of course, is part of the concrete UpdateReference class.
> and then, in the case of a "ReferenceChangeLeftTarget" (addition of a
> value, remote removal of a value) :
> left Target => the value that has been added to -or remotely removed
> from- the reference values list.
> right Target => the matched value of the left Target. If left target
> points to element A from model 1, right target will point to element A'
> from model 2.
I agree that leftTarget and rightTarget should be contained in ReferenceChangeLeftTarget.
However, ReferenceChange.left/rightElement could be replaced by DiffElement.correspondingLeft/RightElement.
> "target" references are used for merge operations, and I cannot set them
> on a common superclass/interface because their types differ : for
> ReferenceChanges they'll be EObjects, for AttributeChanges they'll be
> Objects, some DiffElement won't need them altogether ... though it is
> true some of these references could seem to be movable, I didn't do it
> to allow me further addition of new differences.
The target references indeed don't seem to be movable in a reasonable way.
After thinking about it once more, I still have the feeling that your left/rightElement references could find their way up to DiffElement, but the other references are indeed placed fine.
But this is only my opinion ;-)
The main difference to the current implementation would probably be the different meaning for added/removed elements as already pointed out in my previous post.
Just out of curiosity, what exactly is the difference between UpdateModelElement and MoveModelElement?
Both are used to describe movements, whereas UpdateContainmentFeature is a special case in which the container remains the same.
> Maybe Moritz Eysholdt could give you more information as far as the
> EPatch support goes :), don't know if he monitors this newsgroup.
Ok :-)
Cheers
Patrick
|
|
| | |
| Re: [EMF Compare] ClassCastException in save action and some diff meta model questions [message #620731 is a reply to message #134016] |
Tue, 17 March 2009 05:06 |
| Eclipse User |
|
|
|
Thank you Laurant, that was very informative.
Further comments below.
>> Btw, is there any documentation why you changed the diff meta model
>> from 3.4 to 3.5?
>> - introducing classes for changes in resources
>> - removing classes for changes (e.g. AddAttribute)
>> - renaming references (e.g. ReferenceChangeLeftTarget.leftRemoveTarget
>> to .leftTarget)
>>
>
> All of these changes have been made in an attempt to simplify the Diff
> metamodel and get rid of redundant code and classes. For exeample
> AddAttribute and RemoteRemoveAttribute were both "dummy" classes which
> only purpose was to provide a name for these changes. They have been
> removed and replaced by their common superclass
> "AttributeChangeLeftTarget". There is no real documentation on this API
> breakage apart from the Javadoc itself, but most of these changes are
> listed on https://bugs.eclipse.org/bugs/show_bug.cgi?id=233451 .
I totally agree that the API is much more concise now.
A little bit confusing to me, however, is the current naming. Since I do not consider three-way-compares, it sounds strange to use an AttributeChangeLeftTarget to describe a removed attribute.
But maybe I just need to get used to that ;-)
>> Furthermore I wonder why all the subclasses have their own references
>> to the models (e.g. leftTarget, rightTarget, leftElement, etc) instead
>> of moving these references to a common superclass or interface?
>>
>
> Some changes have links towards left elements, some towards right
> elements, some towards both ... Moving these references to superclasses
> would ruin the Diff Model readability (or so I think). I kept these
> references on the actual DiffElements for this reason alone. If you
> think there would be a better way to order these feel I'd like to hear
> your thoughts :) (though I fear it is too late now as M6 is nigh).
Then we probably have a different opinion about readability ;-) But this is fair enough.
My choice was to add one reference to the DiffElement pointing to the 'correspondingElement' of the source and target model, which is the element that was 'changed'.
The meaning of the correspondingElement differs for the concrete DiffElements:
Attribute changes - correspondingElement is pointing to the element containing the attribute
Reference changes - correspondingElement is pointing to the element containing the reference
Movement - correspondingElement is pointing to the moved element
Addition and deletion - correspondingElement is pointing to the parent element of the added/deleted element
This way, DiffElement.correspondingElement is always pointing to the changed element.
Of course we need more references for most concrete DiffElements..
>> Last question: How is the status about the "patch/changeset model"?
>> The reason I ask is because I am implementing something similar
>> (details in technical report [1]) at the moment (as also mentioned in
>> the post 'Infos about the planned "patch/changeset model" feature?' on
>> 09-09-2008).
>> My status is that I am able to save a model-independent diff; the next
>> step I am working on is to apply it to another model.
>>
>
> The EPatch has recently been committed on CVS HEAD, you can check the
> bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=262928 or the CQ
> https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3063 for more information.
Thanks, I'll give it a try :-)
Best regards
Patrick
|
|
| |
| Re: [EMF Compare] ClassCastException in save action and some diff meta model questions [message #620733 is a reply to message #134070] |
Wed, 18 March 2009 03:23 |
| Eclipse User |
|
|
|
Hi Laurent,
comments again inline.
>>>> Furthermore I wonder why all the subclasses have their own references
>>>> to the models (e.g. leftTarget, rightTarget, leftElement, etc) instead
>>>> of moving these references to a common superclass or interface?
>>>>
>>>
>>> Some changes have links towards left elements, some towards right
>>> elements, some towards both ... Moving these references to superclasses
>>> would ruin the Diff Model readability (or so I think). I kept these
>>> references on the actual DiffElements for this reason alone. If you
>>> think there would be a better way to order these feel I'd like to hear
>>> your thoughts :) (though I fear it is too late now as M6 is nigh).
>>
>> Then we probably have a different opinion about readability ;-) But
>> this is fair enough.
>> My choice was to add one reference to the DiffElement pointing to the
>> 'correspondingElement' of the source and target model, which is the
For clarification, what I implicitly meant:
DiffElement.correspondingLeftElement (to 'left' model)
DiffElement.correspondingRightElement (to 'right' model)
>> element that was 'changed'.
>> The meaning of the correspondingElement differs for the concrete
>> DiffElements:
>> Attribute changes - correspondingElement is pointing to the element
>> containing the attribute
>> Reference changes - correspondingElement is pointing to the element
>> containing the reference
>> Movement - correspondingElement is pointing to the moved element
>> Addition and deletion - correspondingElement is pointing to the parent
>> element of the added/deleted element
>>
>> This way, DiffElement.correspondingElement is always pointing to the
>> changed element.
>> Of course we need more references for most concrete DiffElements..
>>
>
> I don't think this could be done ... to take the exemple of reference
> changes, we have to keep references to :
> left element => the element from the left model containing a reference
> which value(s) changed
> right element => the element from the right model containing a reference
> which value(s) changed
> reference => the actual reference that's been changed
In this case leftElement could be correspondingLeftElement and rightElement correspondingRightElement.
The reference, of course, is part of the concrete UpdateReference class.
> and then, in the case of a "ReferenceChangeLeftTarget" (addition of a
> value, remote removal of a value) :
> left Target => the value that has been added to -or remotely removed
> from- the reference values list.
> right Target => the matched value of the left Target. If left target
> points to element A from model 1, right target will point to element A'
> from model 2.
I agree that leftTarget and rightTarget should be contained in ReferenceChangeLeftTarget.
However, ReferenceChange.left/rightElement could be replaced by DiffElement.correspondingLeft/RightElement.
> "target" references are used for merge operations, and I cannot set them
> on a common superclass/interface because their types differ : for
> ReferenceChanges they'll be EObjects, for AttributeChanges they'll be
> Objects, some DiffElement won't need them altogether ... though it is
> true some of these references could seem to be movable, I didn't do it
> to allow me further addition of new differences.
The target references indeed don't seem to be movable in a reasonable way.
After thinking about it once more, I still have the feeling that your left/rightElement references could find their way up to DiffElement, but the other references are indeed placed fine.
But this is only my opinion ;-)
The main difference to the current implementation would probably be the different meaning for added/removed elements as already pointed out in my previous post.
Just out of curiosity, what exactly is the difference between UpdateModelElement and MoveModelElement?
Both are used to describe movements, whereas UpdateContainmentFeature is a special case in which the container remains the same.
> Maybe Moritz Eysholdt could give you more information as far as the
> EPatch support goes :), don't know if he monitors this newsgroup.
Ok :-)
Cheers
Patrick
|
|
| |
Goto Forum:
Current Time: Mon May 12 10:44:05 EDT 2025
Powered by FUDForum. Page generated in 0.04683 seconds |
Home