QVT transf Ant task has obsolete and inconsistent grammar

[eclipse-qvt-oml-bot]

| --- | --- | | Bugzilla Link | 247429 | | Status | RESOLVED FIXED | | Importance | P3 normal | | Reported | Sep 16, 2008 06:58 EDT | | Modified | May 28, 2009 17:55 EDT | | Version | 1.0 | | Reporter | Radomil Dvorak |

Description

elements are confusing if used for [in], [inout] model params.\ The "sourceUri" attribute is not used at all during execution. Also, validation is incomplete, for instance invalid path for model files is not reported at all.

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Jan 19, 2009 10:37

Adjusting target milestone

[eclipse-qvt-oml-bot]

By Sergey Boyko on Feb 24, 2009 16:36

Example of modified Ant task definition:

<qvto.transformation\ module="ecore2uml.qvto"\ tracefile="ecore2uml.qvtotrace"\

\ <modelParameter\ in_uri="in.ecore"\ />\ <modelParameter\ in_uri="inout.ecore"\ out_uri="inout_res.ecore"\ />\ <modelParameter\ out_uri="ecore2uml.uml#_GV07YK2xEd2wB-Rk-ZcxSg"\ feature="packagedElement"\ clearcontents="true"\ />

<configurationProperty\
    name="prop"\
    value="attr"\
/>\

</qvto.transformation>

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Feb 25, 2009 04:11

I suggest to use namespaces so we do not have to add 'qvto' prefix to the task name. One can then optionally add the namespace prefix.

How about using , , as nested elements? We could avoid a wide set of attributes where only a subset is relevant based on the context of use. These specific elements would definitely have a common base.

I'm also thinking about being a nested element for the future extensibility reasons, in case we would need to add a specific handling for traces.

Just an idea? / a bonus for lazy users ;-) /\

->

[eclipse-qvt-oml-bot]

By Sergey Boyko on Feb 25, 2009 08:35

On comment #3\ Agreed on all points.

Modified example would be:

\ \

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Feb 26, 2009 12:13

(In reply to comment #4)

Also the 'module' attribute should rather be 'uri'.

What still looks a bit odd to me is the feature attribute of element.\ I know we have it for historical reasons, but to me it appears rather as\ inplace transf putting a transformation outcome at a proper place.

In case 'clearcontents' relates to the target feature, can not we \ rather have a nested element?

A last comment ;), 'out_uri' should become 'outuri', more consistent\ with the existing Ant tasks and with us too, like , 'clearcontents'.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Feb 26, 2009 15:17

(In reply to comment #5)

Also the 'module' attribute should rather be 'uri'.

ok

What still looks a bit odd to me is the feature attribute of element. I know we have it for historical reasons, but to me it appears rather as inplace transf putting a transformation outcome at a proper place.

Agree. For ordinary EMF resource there will be no difference as since target is always re-created (saved as a whole) in both cases.\ I think target feature can be eliminated in the new task def.

In case 'clearcontents' relates to the target feature, can not we rather have a nested element?

A last comment ;), 'out_uri' should become 'outuri', more consistent with the existing Ant tasks and with us too, like , 'clearcontents'.

already corrected :)

[eclipse-qvt-oml-bot]

By Sergey Boyko on Feb 26, 2009 16:21

(In reply to comment #6)

(In reply to comment #5)

Also the 'module' attribute should rather be 'uri'. ok

Also 'file' for <trace .. > would be changed to 'uri'.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Feb 26, 2009 16:49

(In reply to comment #5)

What still looks a bit odd to me is the feature attribute of element. I know we have it for historical reasons, but to me it appears rather as inplace transf putting a transformation outcome at a proper place.

One case that could not be expressed with [inout] logic.\ Suppose we have unordered non-unique feature eAllClassifiers[*] and we want to redirect output to some feature under the given classifier. That classifier can be addressed by means of URI but can't be selected from input extent (since it's backed with 'Bag' collection type).

[eclipse-qvt-oml-bot]

By Radomil Dvorak on Feb 27, 2009 04:38

(In reply to comment #8)

One case that could not be expressed with [inout] logic.

I think I could invent 10 more special scenarios ;), the question is\ what is in the scope of a transf. task.\ I would not mind if it is another task executed on the given transf result \ and stores at given uri.

My only concern is clarity of use, which is poor in case of the old tasks.\ If it is not a separate task, at least a nested feature would be more appropriate, IMO.

[eclipse-qvt-oml-bot]

By Sergey Boyko on Mar 07, 2009 08:21

Fixed.\ "Ant tasks support" section was added to QVTO documentation.