Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[qvtd-dev] Issue 13103 - Element creation/attachmenty/detachment (was Re: AW: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2) 
Hi Christopher
Issue 13103 was originally on my helpwanted list, but in the absence of any help, it was one where I thought I could take a shot at it using my intuition. At least it has now provoked some discussion, so we can discuss if 
- I'm right and the proposed resolution stands
- it is easily corrected so we modify it
- we want a more prolonged discussion/research and the resolution is withdrawn. 
No need for a new OMG issue while an existing one is still open.
In Eclipse terms, I interpret residence in an extent as being locateable by Resource.eAllContents(), so for any EObject the extent is just eObject.eResource() [or more pedantically to handle fragmented resources: EcoreUtil.getRootContainer(eObject).eResource()].
Objects created without any residence have a null eResource() and so may be lost.
In the case of mapping results, indeed the mapping has no effect on residence, but since the mapping result is often assigned to a composition, that assignment changes the residence.
The issue addressed only ObjectExp, but if we should extend it to InstantiationExp then lets do so. Please suggest words. 

    Regards

        Ed Willink

On 04/02/2014 10:37, Christopher Gerking wrote:

Hi Ed & Adolfo

I'm not yet convinced by the resolution for issue 13103: element creation and element attachment/detachment to/from an extent.

The proposed resolution targets ObjectExp only. Applying the "short form" to "long form" conversion rules, I expect that the proposed behavior holds for mappings as well. However, does this imply that elements are attached to an extent only on creation, and not reattached whenever they act as a mapping result? To clarify this hehavior, I already raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=425066 for Eclipse QVTo. Without reattaching, there seems to be no reasonable way of adding an element created inside a blackbox to an extent. Adolfo already pointed at the same issue: "there are other times when we need to assign to an extent some model elements that may have been created at an unrelated time."

For the clone/deepclone operations, I just found out that Eclipse QVTo does not behave as described by Adolfo. It does not add the clones to the same extent as the original, but always obtains the proper "default" extent.

Do we require a new OMG issue?


Regards
Christopher



-----Ursprüngliche Nachricht-----
Von: qvto-dev-bounces@xxxxxxxxxxx [mailto:qvto-dev-bounces@xxxxxxxxxxx] Im Auftrag von Ed Willink
Gesendet: Montag, 3. Februar 2014 20:02
An: qvt-rtf@xxxxxxx; QVTOML developer mailing list
Betreff: [qvto-dev] QVT 1.2 RTF Ballot 3 preview 2

Hi

Note that voting for Ballot 1 reballot is still open. Please vote.
Note that voting for Ballot 2 is still open. Please vote.

The second preview of QVT 1.2 RTF Ballot 3 is attached (with change bars since Preview 1).

Preview 30-Jan to 5-Feb
Voting 5-Feb to 19-Feb

Most of the working material may be found at http://svn.omg.org/repos/QVT/trunk/Documents/TaskForces/1.2. Apply to Juergen for a password, and beware of using SVN 1.8 tooling for the 1.4 server (1.7 seems fine).

I have managed to provide simple resolutions to two previously deferred issues.

Issue 12518 is substantially updated to include the redrawn Papyrus diagrams.

The provisional Ecore and UML models and Papyrus diagrams can be found in http://svn.omg.org/repos/QVT/trunk/Documents/Specifications/1.2/Models

      Regards

          Ed Willink




-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4259 / Virus Database: 3684/7058 - Release Date: 02/03/14

Back to the top