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."
---
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
Am 04.03.2016 um 16:50 schrieb Ed Willink:
Hi
I'm not at all fond of a dependency on EMFc. I took some trouble
to eliminate it from OCL tests when they changed APIs
incompatibly.
I don't see why QVTo pretty printing should need EMFc at all.
If you just want it for testing then 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.
Regards
Ed Willink
On 04/03/2016 13:55, Uwe Ritzmann wrote:
Ed,
in the eclipse qvt-oml forum you noted:
> It will save time in due course if you attach, preferably
a GIT patch,
> to a Bugzilla and sign the CLA to indicate your formal
willingness to
> contribute.
Certainly I would be willing to share both the implementation
as well
as the testcases. As already mentioned here I took the freedom
to
introduce a dependency upon EMF Compare.
Would that be ok? Or does that break any conventions?
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
_______________________________________________
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
_______________________________________________
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
|
