Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMF Compare] Bug in detecting added attributes?
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #137334 is a reply to message #137311] |
Tue, 16 June 2009 13:06   |
|
This is a multi-part message in MIME format.
--------------000703020000010802080405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Patrick,
Looking at the image, this indeed looks like a bug. As we are currently
working on the release of Galileo, could you raise a bugzilla for this
with the zips and image so that I don't forget this needs fixing?
Laurent Goubet
Obeo
Patrick K
|
|
| |
| Re: [EMF Compare] Bug in detecting added attributes? [message #137358 is a reply to message #137346] |
Tue, 16 June 2009 15:43 |
|
This is a multi-part message in MIME format.
--------------040107030300030609010203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Thanks, i'll try and investigate some more asap as we haven't detected
such regressions in our tests :(
Patrick K
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #137369 is a reply to message #137358] |
Tue, 16 June 2009 17:04 |
 Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent,
I guess I just catched another unpleasant bug in the other example of the zip (sorry for doing that just before the big release :-/ )
The emfdiff of the Eachonce/eachonce/model_v?.eachonce models contains two UpdateReferences with LeftTarget = RightTarget.
In other words, they do not describe a difference at all ;-)
However, from the two models I expected a change from null to an object, and from an object to null respectively.
I could add that to the existing bug or raise another one? Or did I miss something in this particular case?
Best regards
Patrick
On 16-06-2009 17:43, laurent Goubet wrote:
> Thanks, i'll try and investigate some more asap as we haven't detected
> such regressions in our tests :(
>
> Patrick Könemann a écrit :
>>
>> No problem, looking forward to Galileo :-)
>>
>> Sure, here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280449
>>
>>
>> Patrick
>>
>>
>> On 16-06-2009 15:06, laurent Goubet wrote:
>>> Hi Patrick,
>>>
>>> Looking at the image, this indeed looks like a bug. As we are currently
>>> working on the release of Galileo, could you raise a bugzilla for this
>>> with the zips and image so that I don't forget this needs fixing?
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Patrick Könemann a écrit :
>>>> Cheers,
>>>>
>>>> short version:
>>>> I think I found a bug in added attribute detection as shown here:
>>>> http://img268.imageshack.us/img268/2386/multiattributechange .png
>>>> (using the latest version from the CVS)
>>>>
>>>>
>>>> long(er) version:
>>>>
>>>> I created a small model for testing the detection of all kinds of
>>>> differences:
>>>> http://imm.dtu.dk/~pk/files/eachonce.zip
>>>> http://imm.dtu.dk/~pk/files/eachonce-runtime.zip
>>>>
>>>> eachonce.zip is a plugin project with a very simple ecore model
>>>> (including generated code) with just one EClass and some attributes
>>>> and references.
>>>> eachonce-runtime.zip contains example models for the runtime workbench:
>>>>
>>>> Eachonce/attribute/ - the example above
>>>> Eachonce/eachonce/ - contains all different kinds of differences (14
>>>> in total)
>>>> Eachonce/reference/ - example from
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270439 (fixed)
>>>>
>>>>
>>>> Best regards
>>>> Patrick
>>>
>>
>
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #137381 is a reply to message #137369] |
Wed, 17 June 2009 08:12 |
|
This is a multi-part message in MIME format.
--------------010203050201000400080009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Patrick,
The "*target" references of most DiffElement describe the value that is
to be copied in either direction by the mergers, not the value actually
changed (not sure I am really clear here :p). Thus tests on these values
can yield strange results sometime.
As you've already raised a bugzilla with both examples, you can add a
comment and a more detailed description of the actual issue you see and
how you've detected it ... I need to investigate to see if there is
actually a bug or if it is intended behavior, yet bug fixing isn't our
priority now except for blockers/criticals.
Laurent Goubet
Obeo
Patrick K
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #137448 is a reply to message #137381] |
Thu, 18 June 2009 14:55 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent,
I added steps for reproduction in the bug description.
Furthermore I found a ClassCastException in the 'Properties' tab is open in the compare view.
I also added this issue to that bug (because I couldn't reproduce it with another example - I tried a simple ecore model).
Patrick
On 17-06-2009 10:12, laurent Goubet wrote:
> Hi Patrick,
>
> The "*target" references of most DiffElement describe the value that is
> to be copied in either direction by the mergers, not the value actually
> changed (not sure I am really clear here :p). Thus tests on these values
> can yield strange results sometime.
>
> As you've already raised a bugzilla with both examples, you can add a
> comment and a more detailed description of the actual issue you see and
> how you've detected it ... I need to investigate to see if there is
> actually a bug or if it is intended behavior, yet bug fixing isn't our
> priority now except for blockers/criticals.
>
> Laurent Goubet
> Obeo
>
> Patrick Könemann a écrit :
>> Hi Laurent,
>>
>> I guess I just catched another unpleasant bug in the other example of
>> the zip (sorry for doing that just before the big release :-/ )
>>
>> The emfdiff of the Eachonce/eachonce/model_v?.eachonce models contains
>> two UpdateReferences with LeftTarget = RightTarget.
>> In other words, they do not describe a difference at all ;-)
>>
>> However, from the two models I expected a change from null to an
>> object, and from an object to null respectively.
>> I could add that to the existing bug or raise another one? Or did I
>> miss something in this particular case?
>>
>>
>> Best regards
>> Patrick
>>
>>
>> On 16-06-2009 17:43, laurent Goubet wrote:
>>> Thanks, i'll try and investigate some more asap as we haven't detected
>>> such regressions in our tests :(
>>>
>>> Patrick Könemann a écrit :
>>>>
>>>> No problem, looking forward to Galileo :-)
>>>>
>>>> Sure, here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280449
>>>>
>>>>
>>>> Patrick
>>>>
>>>>
>>>> On 16-06-2009 15:06, laurent Goubet wrote:
>>>>> Hi Patrick,
>>>>>
>>>>> Looking at the image, this indeed looks like a bug. As we are
>>>>> currently
>>>>> working on the release of Galileo, could you raise a bugzilla for this
>>>>> with the zips and image so that I don't forget this needs fixing?
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Patrick Könemann a écrit :
>>>>>> Cheers,
>>>>>>
>>>>>> short version:
>>>>>> I think I found a bug in added attribute detection as shown here:
>>>>>> http://img268.imageshack.us/img268/2386/multiattributechange .png
>>>>>> (using the latest version from the CVS)
>>>>>>
>>>>>>
>>>>>> long(er) version:
>>>>>>
>>>>>> I created a small model for testing the detection of all kinds of
>>>>>> differences:
>>>>>> http://imm.dtu.dk/~pk/files/eachonce.zip
>>>>>> http://imm.dtu.dk/~pk/files/eachonce-runtime.zip
>>>>>>
>>>>>> eachonce.zip is a plugin project with a very simple ecore model
>>>>>> (including generated code) with just one EClass and some attributes
>>>>>> and references.
>>>>>> eachonce-runtime.zip contains example models for the runtime
>>>>>> workbench:
>>>>>>
>>>>>> Eachonce/attribute/ - the example above
>>>>>> Eachonce/eachonce/ - contains all different kinds of differences (14
>>>>>> in total)
>>>>>> Eachonce/reference/ - example from
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270439 (fixed)
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>> Patrick
>>>>>
>>>>
>>>
>>
>
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #621028 is a reply to message #137311] |
Tue, 16 June 2009 13:06 |
|
This is a multi-part message in MIME format.
--------------000703020000010802080405
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Patrick,
Looking at the image, this indeed looks like a bug. As we are currently
working on the release of Galileo, could you raise a bugzilla for this
with the zips and image so that I don't forget this needs fixing?
Laurent Goubet
Obeo
Patrick K
|
|
| |
| Re: [EMF Compare] Bug in detecting added attributes? [message #621030 is a reply to message #137346] |
Tue, 16 June 2009 15:43 |
|
This is a multi-part message in MIME format.
--------------040107030300030609010203
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Thanks, i'll try and investigate some more asap as we haven't detected
such regressions in our tests :(
Patrick K
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #621031 is a reply to message #137358] |
Tue, 16 June 2009 17:04 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent,
I guess I just catched another unpleasant bug in the other example of the zip (sorry for doing that just before the big release :-/ )
The emfdiff of the Eachonce/eachonce/model_v?.eachonce models contains two UpdateReferences with LeftTarget = RightTarget.
In other words, they do not describe a difference at all ;-)
However, from the two models I expected a change from null to an object, and from an object to null respectively.
I could add that to the existing bug or raise another one? Or did I miss something in this particular case?
Best regards
Patrick
On 16-06-2009 17:43, laurent Goubet wrote:
> Thanks, i'll try and investigate some more asap as we haven't detected
> such regressions in our tests :(
>
> Patrick Könemann a écrit :
>>
>> No problem, looking forward to Galileo :-)
>>
>> Sure, here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280449
>>
>>
>> Patrick
>>
>>
>> On 16-06-2009 15:06, laurent Goubet wrote:
>>> Hi Patrick,
>>>
>>> Looking at the image, this indeed looks like a bug. As we are currently
>>> working on the release of Galileo, could you raise a bugzilla for this
>>> with the zips and image so that I don't forget this needs fixing?
>>>
>>> Laurent Goubet
>>> Obeo
>>>
>>> Patrick Könemann a écrit :
>>>> Cheers,
>>>>
>>>> short version:
>>>> I think I found a bug in added attribute detection as shown here:
>>>> http://img268.imageshack.us/img268/2386/multiattributechange .png
>>>> (using the latest version from the CVS)
>>>>
>>>>
>>>> long(er) version:
>>>>
>>>> I created a small model for testing the detection of all kinds of
>>>> differences:
>>>> http://imm.dtu.dk/~pk/files/eachonce.zip
>>>> http://imm.dtu.dk/~pk/files/eachonce-runtime.zip
>>>>
>>>> eachonce.zip is a plugin project with a very simple ecore model
>>>> (including generated code) with just one EClass and some attributes
>>>> and references.
>>>> eachonce-runtime.zip contains example models for the runtime workbench:
>>>>
>>>> Eachonce/attribute/ - the example above
>>>> Eachonce/eachonce/ - contains all different kinds of differences (14
>>>> in total)
>>>> Eachonce/reference/ - example from
>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270439 (fixed)
>>>>
>>>>
>>>> Best regards
>>>> Patrick
>>>
>>
>
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #621032 is a reply to message #137369] |
Wed, 17 June 2009 08:12 |
|
This is a multi-part message in MIME format.
--------------010203050201000400080009
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Hi Patrick,
The "*target" references of most DiffElement describe the value that is
to be copied in either direction by the mergers, not the value actually
changed (not sure I am really clear here :p). Thus tests on these values
can yield strange results sometime.
As you've already raised a bugzilla with both examples, you can add a
comment and a more detailed description of the actual issue you see and
how you've detected it ... I need to investigate to see if there is
actually a bug or if it is intended behavior, yet bug fixing isn't our
priority now except for blockers/criticals.
Laurent Goubet
Obeo
Patrick K
|
|
|
| Re: [EMF Compare] Bug in detecting added attributes? [message #621038 is a reply to message #137381] |
Thu, 18 June 2009 14:55 |
Patrick Konemann
Messages: 116
Registered: July 2009 |
Senior Member |
|
|
Hi Laurent,
I added steps for reproduction in the bug description.
Furthermore I found a ClassCastException in the 'Properties' tab is open in the compare view.
I also added this issue to that bug (because I couldn't reproduce it with another example - I tried a simple ecore model).
Patrick
On 17-06-2009 10:12, laurent Goubet wrote:
> Hi Patrick,
>
> The "*target" references of most DiffElement describe the value that is
> to be copied in either direction by the mergers, not the value actually
> changed (not sure I am really clear here :p). Thus tests on these values
> can yield strange results sometime.
>
> As you've already raised a bugzilla with both examples, you can add a
> comment and a more detailed description of the actual issue you see and
> how you've detected it ... I need to investigate to see if there is
> actually a bug or if it is intended behavior, yet bug fixing isn't our
> priority now except for blockers/criticals.
>
> Laurent Goubet
> Obeo
>
> Patrick Könemann a écrit :
>> Hi Laurent,
>>
>> I guess I just catched another unpleasant bug in the other example of
>> the zip (sorry for doing that just before the big release :-/ )
>>
>> The emfdiff of the Eachonce/eachonce/model_v?.eachonce models contains
>> two UpdateReferences with LeftTarget = RightTarget.
>> In other words, they do not describe a difference at all ;-)
>>
>> However, from the two models I expected a change from null to an
>> object, and from an object to null respectively.
>> I could add that to the existing bug or raise another one? Or did I
>> miss something in this particular case?
>>
>>
>> Best regards
>> Patrick
>>
>>
>> On 16-06-2009 17:43, laurent Goubet wrote:
>>> Thanks, i'll try and investigate some more asap as we haven't detected
>>> such regressions in our tests :(
>>>
>>> Patrick Könemann a écrit :
>>>>
>>>> No problem, looking forward to Galileo :-)
>>>>
>>>> Sure, here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=280449
>>>>
>>>>
>>>> Patrick
>>>>
>>>>
>>>> On 16-06-2009 15:06, laurent Goubet wrote:
>>>>> Hi Patrick,
>>>>>
>>>>> Looking at the image, this indeed looks like a bug. As we are
>>>>> currently
>>>>> working on the release of Galileo, could you raise a bugzilla for this
>>>>> with the zips and image so that I don't forget this needs fixing?
>>>>>
>>>>> Laurent Goubet
>>>>> Obeo
>>>>>
>>>>> Patrick Könemann a écrit :
>>>>>> Cheers,
>>>>>>
>>>>>> short version:
>>>>>> I think I found a bug in added attribute detection as shown here:
>>>>>> http://img268.imageshack.us/img268/2386/multiattributechange .png
>>>>>> (using the latest version from the CVS)
>>>>>>
>>>>>>
>>>>>> long(er) version:
>>>>>>
>>>>>> I created a small model for testing the detection of all kinds of
>>>>>> differences:
>>>>>> http://imm.dtu.dk/~pk/files/eachonce.zip
>>>>>> http://imm.dtu.dk/~pk/files/eachonce-runtime.zip
>>>>>>
>>>>>> eachonce.zip is a plugin project with a very simple ecore model
>>>>>> (including generated code) with just one EClass and some attributes
>>>>>> and references.
>>>>>> eachonce-runtime.zip contains example models for the runtime
>>>>>> workbench:
>>>>>>
>>>>>> Eachonce/attribute/ - the example above
>>>>>> Eachonce/eachonce/ - contains all different kinds of differences (14
>>>>>> in total)
>>>>>> Eachonce/reference/ - example from
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=270439 (fixed)
>>>>>>
>>>>>>
>>>>>> Best regards
>>>>>> Patrick
>>>>>
>>>>
>>>
>>
>
|
|
|
Goto Forum:
Current Time: Sat Jul 27 04:48:26 GMT 2024
Powered by FUDForum. Page generated in 0.04285 seconds |
] 
Search
Help
Register
Login
Home
