Re: [qvto-dev] mechanics of contributing QvtOperationalResourceImpl.save

[Sergey Boyko <serg.boyko2011@xxxxxxxxx>]

Hi Uwe,

On Sun, Mar 6, 2016 at 8:37 PM, Uwe Ritzmann <eclipse@xxxxxxxxxxxxxxx> wrote:

Hi Ed,

I did look at TestUtil.assertSameModel. As far as I understood it, it just stringifies the left and right model and compares on equality.
I rather need a diff util because in some testcases there are differences that I can not hold against my unparser,
e.g. the QVTo-Parser inserts implicit set conversions that my parser does not bother to eliminate or sometimes the orderings
of top level classifiers like "Bag(String)", "Set(EClass)" etc. are changed. So sometimes I accept a number of diffs.
I am trying to stay in the existing approach of the Parser tests which are similarly parametrized by expected errors or warnings.

The  'org.eclipse.m2m.tests.qvt.oml.api.framework.comparator' framework which I mentioned is tolerated for such changes between trees under compare so I think it can be successfully used in your scenario.

 

So, would org.eclipse.compare be acceptable?

I think that dependency to 'org.eclipse.compare' is acceptable. However it's always better to localize additional dependencies into separate plug-in and utilize Eclipse extension mechanism to exploit the functionality.