Hi
I solve the problem of different-same with a custom Normalizer that
rewrites (and optionally restores too).
For OCL and QVTd that have disciplined models and conversion, I find
very little normalization necessary. For less-disciplined test
models I have to work harder. See
/org.eclipse.qvtd.xtext.qvtcore.tests/src/org/eclipse/qvtd/xtext/qvtcore/tests/upper2lower/Upper2LowerNormalizer.java
You may want to apply an alphabetic sort to e.g.
Module::ownedVariable. Arguably the CS2AS could do this anyway in
the interests of making the AS more readable with the Sample Ecore
Model Editor. OMG defines Module::ownedVariable as not ordered, and
the EMF implementation preserves that declaration even though an
EList is used which does actually preserve an order.
(ECollections.sort is needed to sort ELists without a crash.) A
pragmatic ordering of the unordered lists also helps stabilize
regenerations of the AS. Your tests won't work until CS2AS is
repeatable.
Regards
Ed Willink
On 06/03/2016 17:37, Uwe Ritzmann
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.
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
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
|
