|
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.
So, would org.eclipse.compare be acceptable?
Am 06.03.2016 um 17:43 schrieb Ed Willink:
Hi
I doubt that org.eclipse.compare will be useful. The whol point of
EMFc is that it abstyracts to model-relevant comparison.
"have a look at
org.eclipse.ocl.examples.xtext.tests.TestUtil.assertSameModel
that exploits
org.eclipse.xtext.util.EmfFormatter
to give results that play nicely with JUnit."
---
Yes, my unparser exceeds 1000 lines:
The QvtOperationalResourceImpl.java changes by only a dozen lines or
so as the unparsing is done in an UnparsingQVTOVisitor.java
which currently has 3731 lines.
Best Regards
Uwe
Copying from QVTo is not a problem. If you are copying entire
source models, better to just reference them where they are than
copy them.
Assuming your contribution exceeds the line limit (1000 lines I
think now) it will need IP approval and we can just assert that
you/existing QVTo is the 'author'.
If this code is to go into Neon, it needs to go to IP for approval
well before release date. The IP team gets quite busy before
releases so the sooner the better. Bugs can still be fixed after
IP approval.
Regards
Ed Willink
On 06/03/2016 15:19, Uwe Ritzmann
wrote:
Hi
1.) EMFCompare is not used for pretty printing. It is used for
comparing the AST from an original transformation file
against the AST from the unparsed copy of that file.
As I am producing qvtox-Versions of both ASTs anyway, I could
use org.eclipse.compare functionality to compare these.
Would that be acceptable?
2.) I signed the CLA, which clearly requests that I only
contribute my own work.
The input to my testcases were blatantly copied from any qvto
file that I could find in the qvto-git repository, assuming
that these files are already under EPL or licensed in a
compliant way. How can this be handled?
Best Regards
Uwe
|
