Element::clone(), deepClone() should involve intermediate properties

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 254962 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Nov 11, 2008 18:33 EDT | | Modified | Mar 19, 2013 01:43 EDT | | Version | 1.0 | | Blocks | 398009 | | Reporter | Radomil Dvorak |

Description

The current implementation does not take into accounts possible intermediate properties. \ If defined, their values should copied into the target copy object too.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 11, 2013 16:12

Created attachment 225519 (attachment deleted)\ JUnit test patch

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 11, 2013 16:13

Created attachment 225520 Patch around an EcoreUtil.Copier subclass that clones intermediate properties

:notepad_spiral: bug254962.patch

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 24, 2013 08:37

Hi Christopher,

I'm quite puzzled with this 'bug254962.qvto' example:

1. The QVTo editor (Kepler M4) has errors with the file
2. The transformations declare the import statements, however the transformations itself don't "access" or "extend" anyone.
3. There is a mapping called "main" and no transformation input parameters ?. It looks like the legacy borland QVTo behaviour.

I'm wondering why the test case works.... any magic around these legacy transformations ?.

Cheers,\ Adolfo.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 25, 2013 06:46

1. I think you refer to the importing error. This is common to all test cases that are distributed among multiple modules. The reason is that, in order to make the import resolvable at runtime, it must be specified relative to the 'parserTestData' folder. I'm not sure whether my fix for bug 390182 would solve that issue.

2. Extension is the default import mechanism. If you specifiy neither 'extends' nor 'access', then 'extends' is applied implicitly.

3. It is exactly the legacy borland QVTo behaviour. I copied the "frame" for the test case from one of the previously existing test cases.

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Jan 25, 2013 06:53

Since I have a mess with all the bugzillas. I'll temporarily remove the dependency from 390182. Once the patch is applied and the related bugs are closed we might have a look to this one.

Cheers,\ Adolfo,

[eclipse-qvt-oml-bot]

By Christopher Gerking on Jan 25, 2013 08:23

I consider the import errors as a limitation of the testing framework. In order to be executable, imports must be specified in a way that unfortunately raises a compile error. It's the same with existing test cases like e.g. 'importedExtents'.

I will adjust the "legacy" style of the test transformation. The bugfix itself still looks good to me.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Feb 01, 2013 10:34

Created attachment 226457 (attachment deleted)\ JUnit test patch

Avoids deprecated syntax usage

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 12, 2013 08:44

Hi Christopher,

The patch looks fine to me and this one it's a very useful bug fix. So I'd +1, however there is one test case failing (javaless_bug254962):

junit.framework.AssertionFailedError: Imported unit 'models::bug254962::Middle_javaless' has compilation errors, line:1, path:models/bug254962/bug254962_javaless.qvto

Do you know what this javaless test "variant" means ?

On the other hand\ (In reply to comment #4)\

2. Extension is the default import mechanism. If you specifiy neither 'extends' nor 'access', then 'extends' is applied implicitly.

This is quite arguable. Could you point me out to somewhere in the specification which may you interpret that ?. Actually, by default I'd always expect access semantics (like in Java).

Cheers,\ Adolfo.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 12, 2013 09:52

(In reply to comment #8)

Do you know what this javaless test "variant" means ?

I think it means executing QVTo transformations in a "standalone" environment, without having the generated Java code of the underlying ecore meta-models.

I once had similar problems with scripts that were calling the EOperations declared in the ecore, or accessed derived features. I think none of this applies to the current problem...

If this is a constant problem, there is one remedy in terms of the JAVALESS_EXCLUDES set in class TransformTests.

This is quite arguable. Could you point me out to somewhere in the specification which may you interpret that ?. Actually, by default I'd always expect access semantics (like in Java).

I had the same expectation in the beginning. Maybe I was just reciting the practice applied by Borland. Try to import something without an import kind, and e.g. you will notice that you are able to override operations from there. I once stepped into the code and recognized that extension is implicitly applied. No evidence from the spec, though.

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 12, 2013 11:02

Very interesting...

We are having different results with this javaless test cases.

Firstly, it complains with the first import line, which is incorrect (the editor shows an error). So if you simply say "import Middle" the editor doesnt complain and the javaless test case complains with a different error.

The point is that the "normal" test case passes... what's different and how can it properly deal with the failing import?.... Very weird.

Actually, If I add the "extends Middle(ecore, ecore)" I receive different error output from the test case.... We should investigate this.

In any case, I'm inclined to include this patch for M6 and open a new bugzilla to study this javaless test cases. What do you think ?.

Cheers,\ Adolfo.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 13, 2013 09:11

(In reply to comment #10)

Firstly, it complains with the first import line, which is incorrect (the editor shows an error). So if you simply say "import Middle" the editor doesnt complain and the javaless test case complains with a different error.

This is exactly the tradeoff discussed for bug 390182, compile errors vs. runtime problems. Borland obviously went for executable test cases, accepting the compile errors shown in the editor.\

The point is that the "normal" test case passes... what's different and how can it properly deal with the failing import?.... Very weird.

Seems as if the javaless test cases have pre-assigned the "ecore" identifier. If we reference the ecore meta-model as "ecore" or "Ecore", it fails. Note that the line count indicated by the JUnit is "wrong" since it is based on some temporary file "bug254962_javaless.qvto" which is automatically created. No idea how this done, though. \

In any case, I'm inclined to include this patch for M6 and open a new bugzilla to study this javaless test cases. What do you think ?.

Now that normal and javaless work for me, I will just provide a new patch.

[eclipse-qvt-oml-bot]

By Christopher Gerking on Mar 13, 2013 09:27

Created attachment 228342 JUnit test patch

Adapted the JUnit patch.

Note that the editor still shows compile errors, like it does for all other existing test cases that import other modules. As mentioned above, this is basically a resolver limitation discussed separately for bug 390182. Our problem was a different one.

:notepad_spiral: testBug254962.patch

[eclipse-qvt-oml-bot]

By Adolfo Sanchez-Barbudo Herrera on Mar 13, 2013 13:58

Thx Christopher,

Patches committed [1] and pushed to master for Kepler M6.

Resolving as fixed.

[1] f70c71c0c8efa3a6ba4e64498c2712b0e037d7f2

[eclipse-qvt-oml-bot]

By Philipp W. Kutter on Mar 19, 2013 01:43

What is missing to put this to verified?