Home » Archived » M2M (model-to-model transformation) » [QVTO] Adding custom operations for primitive data types
| [QVTO] Adding custom operations for primitive data types [message #77369] |
Sat, 22 March 2008 05:46  |
|
Hello guys,
It's me again. I'm not sure if this the right place to ask, but for my
transformation I have a comma-separated string and I need to split it.
From the OCL spec, I can see that the operations supported by the String
datatype are size(), concat(), substring(), toInteger() and toReal(), but
there's no split() operation. Is there a way to extend the OCL or QVTO
plug-in to add new operations to the String datatype? I know you rely on
the OCL plugin of the MDT project, but I also saw you guys kind of add
custom code to it, since there's a plugin called
org.eclipse.m2m.qvt.oml.ocl and others like that.
Can you give me the steps to follow? I know this is a lot of work and I
have to read a lot, but can you point me in the right direction?
Thanks again ;)
-Juan
|
|
|
| Re: [QVTO] Adding custom operations for primitive data types [message #77426 is a reply to message #77369] |
Tue, 25 March 2008 11:55  |
Eclipse User |
|
|
|
Originally posted by: Alexander.Igdalov.borland.com
Hi Juan,
It is possible to add custom libraries to QVTO. You can use the extract
from our Together documentation below. It is slightly out of date, so
you may use org.eclipse.m2m.qvt.oml.ocl.emf.libraries.StringLibrary as
an example.
========================
QVT extensively uses OCL, adding a "write" capability to this
"read-only" language through a number of special constructs. These
QVT-specific constructs are described below.
QVT implementation allows to call Java methods from within QVT sources.
The mechanism used is identical to the one used for calling Java methods
from OCL code. It allows to view specially written methods of a Java
class as QVT operations.
Let's consider a simple example of defining a new dumpErr operation with
the following signature: OclAny::dumpErr(in prefix: String): OclAny.
This operation prints the string representation of self, prepended by
the prefix to a standard error, and returns self as the result.
Note: The context parameter self is passed as the first parameter of
the dumpErr operation. For OclVoid context, this parameter is omitted.
First, we need a Java class implementing the operation:
package qvtlib;
public class SampleLibrary {
public Object dumpErr(Object self, String prefix) {
System.err.println(prefix + self);
return self;
}
public static class Metainfo {
private static final String[] DUMP_ERR = new String[] {
"OclAny", "String", "OclAny" };
public static String[] dumpErr(Object self, String prefix)
{
return DUMP_ERR;
}
}
}
Note that the context parameter self is passed as the first parameter of
the dumpErr operation. In case of OclVoid context, this parameter is
omitted.
Static Metainfo class provides information on the signatures of the
exported operations. Each exported operation should provide
metainformation through the static method of this class. The method
should have the same signature as the operation being described, and the
String[] return type. The returned array should contain OCL type names
and is interpreted as follows.
array[0] -- context type
array[1]..array[array.length-2] -- parameter type(s)
array[array.length-1] -- return type
SampleLibrary class must reside in the Eclipse plug-in which should also
provide a org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension:
<extension point="org.eclipse.m2m.qvt.oml.ocl.emf.libraries">
<library class="qvtlib.SampleLibrary"
id="qvtlib.SampleLibrary">
<inMetamodel
uri="http://www.eclipse.org/emf/2002/Ecore"/>
<outMetamodel
uri="http://www.eclipse.org/emf/2002/Ecore"/>
</library>
</extension>
Extension specifies a library id (qvtlib.SampleLibrary), and,
optionally, metamodels required by the library
(http://www.eclipse.org/emf/2002/Ecore in our case).
When the plug-in is deployed and available to the Workbench, the
qvtlib.SampleLibrary library becomes available to QVT transformations
and OCL scripts. It can be used with any QVT transformation whose
transformation project has a dependency on the library plug-in. For example:
transformation Ecore_To_Ecore;
import library qvtlib.SampleLibrary;
metamodel 'http://www.eclipse.org/emf/2002/Ecore';
query dump(in model: ecore::EPackage): OclAny {
model.dumpErr('model: ');
}
The above dumpErr call will be converted to the following Java code:
new qvtlib.SampleLibrary().dumpErr(model, "model: "));
==========================
Interestingly, StringLibrary has had split-operations that you need. For
some reason, they were commented out and became unavailable. I've just
committed split operation support and you can download QVTO sources (I
hope downloading org.eclipse.m2m.qvt.oml.ocl.emf.libraries plugin is
enough) to have them right away. An appropriate integration build will
be published ASAP.
Cheers,
Alex.
Juan Jose Cadavid G wrote:
> Hello guys,
>
> It's me again. I'm not sure if this the right place to ask, but for my
> transformation I have a comma-separated string and I need to split it.
> From the OCL spec, I can see that the operations supported by the
> String datatype are size(), concat(), substring(), toInteger() and
> toReal(), but there's no split() operation. Is there a way to extend the
> OCL or QVTO plug-in to add new operations to the String datatype? I know
> you rely on the OCL plugin of the MDT project, but I also saw you guys
> kind of add custom code to it, since there's a plugin called
> org.eclipse.m2m.qvt.oml.ocl and others like that.
>
> Can you give me the steps to follow? I know this is a lot of work and I
> have to read a lot, but can you point me in the right direction?
>
> Thanks again ;)
>
> -Juan
>
|
|
|
| Re: [QVTO] Adding custom operations for primitive data types [message #77472 is a reply to message #77426] |
Wed, 26 March 2008 12:54 |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Alex,
This seems to be an interesting way to create new operations for ocl
types or even, for new types. I suppose that you support
QVToStandardLibrary using this kind of mechanisms. Perhaps "split" is a
commented operation since it doesn't take part in the QVto Standard Li
brary...
Anyway, specification talks about the existence of a QVTo Standard
Library (an instance of QVToperational::Library called StdLib) which
should contain the QVTo specific Types, and the type extensions of the
OclTypes.
Ideally, this QVTo standard library could be persisted as a model, and
any QVToperational model should be able to refer to the Standrad Library
types, operations, etc, in the same way that OCLExpressions refers to
its OCL Standard Library types and operations. Besides, the
QVToStandardLibrary should pretentiously "extend" the OCLStandardLibrary
one (as the specification says).
Actually, the oclStandardLibrary is not extensible with the actual
MDT-OCL implementation, since the implementation of the ocl Types are
coupled with the internal OclStandardLibrary implementation. I'm working
with Christian to solve this problem, and I have found an "smart"
solution which I have to contrast with him. I'm trying to find more
alternative solutions to this problem, since it will probably involve
additions to the actual API. We should lead this resolution to the best
one...
Perhaps the use of this libraries extension points, could be thought as
the registration of the standard library, although I think that, at
least, the QVToStandardLibrary should be treated as a true model...
Best Regards,
Adolfo.
Alexander Igdalov escribió:
> Hi Juan,
>
> It is possible to add custom libraries to QVTO. You can use the extract
> from our Together documentation below. It is slightly out of date, so
> you may use org.eclipse.m2m.qvt.oml.ocl.emf.libraries.StringLibrary as
> an example.
>
> ========================
> QVT extensively uses OCL, adding a "write" capability to this
> "read-only" language through a number of special constructs. These
> QVT-specific constructs are described below.
> QVT implementation allows to call Java methods from within QVT sources.
> The mechanism used is identical to the one used for calling Java methods
> from OCL code. It allows to view specially written methods of a Java
> class as QVT operations.
> Let's consider a simple example of defining a new dumpErr operation with
> the following signature: OclAny::dumpErr(in prefix: String): OclAny.
> This operation prints the string representation of self, prepended by
> the prefix to a standard error, and returns self as the result.
> Note: The context parameter self is passed as the first parameter of
> the dumpErr operation. For OclVoid context, this parameter is omitted.
>
> First, we need a Java class implementing the operation:
> package qvtlib;
>
> public class SampleLibrary {
> public Object dumpErr(Object self, String prefix) {
> System.err.println(prefix + self);
> return self;
> }
>
> public static class Metainfo {
> private static final String[] DUMP_ERR = new String[] {
> "OclAny", "String", "OclAny" };
>
> public static String[] dumpErr(Object self, String prefix)
> {
> return DUMP_ERR;
> }
> }
> }
>
> Note that the context parameter self is passed as the first parameter of
> the dumpErr operation. In case of OclVoid context, this parameter is
> omitted.
> Static Metainfo class provides information on the signatures of the
> exported operations. Each exported operation should provide
> metainformation through the static method of this class. The method
> should have the same signature as the operation being described, and the
> String[] return type. The returned array should contain OCL type names
> and is interpreted as follows.
> array[0] -- context type
> array[1]..array[array.length-2] -- parameter type(s)
> array[array.length-1] -- return type
> SampleLibrary class must reside in the Eclipse plug-in which should also
> provide a org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension:
> <extension point="org.eclipse.m2m.qvt.oml.ocl.emf.libraries">
> <library class="qvtlib.SampleLibrary"
> id="qvtlib.SampleLibrary">
> <inMetamodel
> uri="http://www.eclipse.org/emf/2002/Ecore"/>
> <outMetamodel
> uri="http://www.eclipse.org/emf/2002/Ecore"/>
> </library>
> </extension>
>
> Extension specifies a library id (qvtlib.SampleLibrary), and,
> optionally, metamodels required by the library
> (http://www.eclipse.org/emf/2002/Ecore in our case).
> When the plug-in is deployed and available to the Workbench, the
> qvtlib.SampleLibrary library becomes available to QVT transformations
> and OCL scripts. It can be used with any QVT transformation whose
> transformation project has a dependency on the library plug-in. For
> example:
> transformation Ecore_To_Ecore;
> import library qvtlib.SampleLibrary;
>
> metamodel 'http://www.eclipse.org/emf/2002/Ecore';
>
> query dump(in model: ecore::EPackage): OclAny {
> model.dumpErr('model: ');
> }
>
> The above dumpErr call will be converted to the following Java code:
> new qvtlib.SampleLibrary().dumpErr(model, "model: "));
> ==========================
>
> Interestingly, StringLibrary has had split-operations that you need. For
> some reason, they were commented out and became unavailable. I've just
> committed split operation support and you can download QVTO sources (I
> hope downloading org.eclipse.m2m.qvt.oml.ocl.emf.libraries plugin is
> enough) to have them right away. An appropriate integration build will
> be published ASAP.
>
> Cheers,
> Alex.
>
>
> Juan Jose Cadavid G wrote:
>> Hello guys,
>>
>> It's me again. I'm not sure if this the right place to ask, but for my
>> transformation I have a comma-separated string and I need to split it.
>> From the OCL spec, I can see that the operations supported by the
>> String datatype are size(), concat(), substring(), toInteger() and
>> toReal(), but there's no split() operation. Is there a way to extend
>> the OCL or QVTO plug-in to add new operations to the String datatype?
>> I know you rely on the OCL plugin of the MDT project, but I also saw
>> you guys kind of add custom code to it, since there's a plugin called
>> org.eclipse.m2m.qvt.oml.ocl and others like that.
>>
>> Can you give me the steps to follow? I know this is a lot of work and
>> I have to read a lot, but can you point me in the right direction?
>>
>> Thanks again ;)
>>
>> -Juan
>>
|
|
|
| Re: [QVTO] Adding custom operations for primitive data types [message #77487 is a reply to message #77472] |
Wed, 26 March 2008 13:51 |
Radomil Dvorak
Messages: 249
Registered: July 2009 |
Senior Member |
|
|
Hi Adolfo,
This extension point is a legacy way of registering native operations
which came from the
original Borland QVT implementation.
Currently, our QVTO Standard library uses the same mechanism as MDT OCL
for operation
call dispatching, the library model is generated on they fly and is
incomplete.
Surely, having the complete QVT StdLib as a model is neccessary and I'm
currently making changes in this
direction.
Conceptually, I think it would reasonable to achieve the following:
1) the user can write QVT library concrete syntax as black-box library,
providing headers for operations, etc.
---parse ---> AST Model,
2) AST Model --transform--> GenModel, GenModel --generate--> Java source
code
- there could be a specific QVT gen-model, but I also think that
annotated ecore and corresponding gen models could be used too,
to leverage existing functionality for generation + merge
3) extension point - resolving the library impl for a given QVT source
file or AST model, loading.
- includes dispatching the AST call to the black-box implementation
-> basically, there could be arbitrary structure of the java impl that
might be hooked into the
QVT engine by a common API, which would be fairly simple in this case.
QVT StdLib, might be treated as any other blackbox library, and have its
java implementation generated
-> empty operation skeletons initially, like with EMF.
As for the "extension" of OCL Standard library, for the beginning I would
be happy to reference it
just as any model, which is currently possible.
I think, the term "extends" is quite bold in this context, and to me, the
spec is not very convincing
there should be really an OCL Library (QVToperational::Library) instance
of it and "extends" relationship
in terms of QVT. /*May be I have overlooked something there ;-) */
Also, IMO, the model of OCL Standard Library pretty belongs to the scope
of OCL spec and I would not
expect it to conform to QVTO metamodel.
Regards,
/Radek
On Wed, 26 Mar 2008 13:54:32 +0100, Adolfo Sánchez-Barbudo Herrera
<adolfosbh@opencanarias.com> wrote:
> Hi Alex,
>
> This seems to be an interesting way to create new operations for ocl
> types or even, for new types. I suppose that you support
> QVToStandardLibrary using this kind of mechanisms. Perhaps "split" is a
> commented operation since it doesn't take part in the QVto Standard Li
> brary...
>
> Anyway, specification talks about the existence of a QVTo Standard
> Library (an instance of QVToperational::Library called StdLib) which
> should contain the QVTo specific Types, and the type extensions of the
> OclTypes.
>
> Ideally, this QVTo standard library could be persisted as a model, and
> any QVToperational model should be able to refer to the Standrad Library
> types, operations, etc, in the same way that OCLExpressions refers to
> its OCL Standard Library types and operations. Besides, the
> QVToStandardLibrary should pretentiously "extend" the OCLStandardLibrary
> one (as the specification says).
>
> Actually, the oclStandardLibrary is not extensible with the actual
> MDT-OCL implementation, since the implementation of the ocl Types are
> coupled with the internal OclStandardLibrary implementation. I'm working
> with Christian to solve this problem, and I have found an "smart"
> solution which I have to contrast with him. I'm trying to find more
> alternative solutions to this problem, since it will probably involve
> additions to the actual API. We should lead this resolution to the best
> one...
>
> Perhaps the use of this libraries extension points, could be thought as
> the registration of the standard library, although I think that, at
> least, the QVToStandardLibrary should be treated as a true model...
>
> Best Regards,
> Adolfo.
>
> Alexander Igdalov escribió:
>> Hi Juan,
>> It is possible to add custom libraries to QVTO. You can use the
>> extract from our Together documentation below. It is slightly out of
>> date, so you may use
>> org.eclipse.m2m.qvt.oml.ocl.emf.libraries.StringLibrary as an example.
>> ========================
>> QVT extensively uses OCL, adding a "write" capability to this
>> "read-only" language through a number of special constructs. These
>> QVT-specific constructs are described below.
>> QVT implementation allows to call Java methods from within QVT sources.
>> The mechanism used is identical to the one used for calling Java
>> methods from OCL code. It allows to view specially written methods of a
>> Java class as QVT operations.
>> Let's consider a simple example of defining a new dumpErr operation
>> with the following signature: OclAny::dumpErr(in prefix: String):
>> OclAny. This operation prints the string representation of self,
>> prepended by the prefix to a standard error, and returns self as the
>> result.
>> Note: The context parameter self is passed as the first parameter of
>> the dumpErr operation. For OclVoid context, this parameter is omitted.
>> First, we need a Java class implementing the operation:
>> package qvtlib;
>> public class SampleLibrary {
>> public Object dumpErr(Object self, String prefix) {
>> System.err.println(prefix + self);
>> return self;
>> }
>> public static class Metainfo {
>> private static final String[] DUMP_ERR = new String[] {
>> "OclAny", "String", "OclAny" };
>> public static String[] dumpErr(Object self, String prefix)
>> {
>> return DUMP_ERR;
>> }
>> }
>> }
>> Note that the context parameter self is passed as the first parameter
>> of the dumpErr operation. In case of OclVoid context, this parameter is
>> omitted.
>> Static Metainfo class provides information on the signatures of the
>> exported operations. Each exported operation should provide
>> metainformation through the static method of this class. The method
>> should have the same signature as the operation being described, and
>> the String[] return type. The returned array should contain OCL type
>> names and is interpreted as follows.
>> array[0] -- context type
>> array[1]..array[array.length-2] -- parameter type(s)
>> array[array.length-1] -- return type
>> SampleLibrary class must reside in the Eclipse plug-in which should
>> also provide a org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension:
>> <extension point="org.eclipse.m2m.qvt.oml.ocl.emf.libraries">
>> <library class="qvtlib.SampleLibrary"
>> id="qvtlib.SampleLibrary">
>> <inMetamodel
>> uri="http://www.eclipse.org/emf/2002/Ecore"/>
>> <outMetamodel
>> uri="http://www.eclipse.org/emf/2002/Ecore"/>
>> </library>
>> </extension>
>> Extension specifies a library id (qvtlib.SampleLibrary), and,
>> optionally, metamodels required by the library
>> (http://www.eclipse.org/emf/2002/Ecore in our case).
>> When the plug-in is deployed and available to the Workbench, the
>> qvtlib.SampleLibrary library becomes available to QVT transformations
>> and OCL scripts. It can be used with any QVT transformation whose
>> transformation project has a dependency on the library plug-in. For
>> example:
>> transformation Ecore_To_Ecore;
>> import library qvtlib.SampleLibrary;
>> metamodel 'http://www.eclipse.org/emf/2002/Ecore';
>> query dump(in model: ecore::EPackage): OclAny {
>> model.dumpErr('model: ');
>> }
>> The above dumpErr call will be converted to the following Java code:
>> new qvtlib.SampleLibrary().dumpErr(model, "model: "));
>> ==========================
>> Interestingly, StringLibrary has had split-operations that you need.
>> For some reason, they were commented out and became unavailable. I've
>> just committed split operation support and you can download QVTO
>> sources (I hope downloading org.eclipse.m2m.qvt.oml.ocl.emf.libraries
>> plugin is enough) to have them right away. An appropriate integration
>> build will be published ASAP.
>> Cheers,
>> Alex.
>> Juan Jose Cadavid G wrote:
>>> Hello guys,
>>>
>>> It's me again. I'm not sure if this the right place to ask, but for my
>>> transformation I have a comma-separated string and I need to split it.
>>> From the OCL spec, I can see that the operations supported by the
>>> String datatype are size(), concat(), substring(), toInteger() and
>>> toReal(), but there's no split() operation. Is there a way to extend
>>> the OCL or QVTO plug-in to add new operations to the String datatype?
>>> I know you rely on the OCL plugin of the MDT project, but I also saw
>>> you guys kind of add custom code to it, since there's a plugin called
>>> org.eclipse.m2m.qvt.oml.ocl and others like that.
>>>
>>> Can you give me the steps to follow? I know this is a lot of work and
>>> I have to read a lot, but can you point me in the right direction?
>>>
>>> Thanks again ;)
>>>
>>> -Juan
>>>
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
|
|
|
| Re: [QVTO] Adding custom operations for primitive data types [message #77642 is a reply to message #77487] |
Thu, 27 March 2008 13:09 |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Radek,
Yeah, the specification doesn't help too much.
In fact, the specification talks about "additions"...WoooW.
The concept of library is missed in OCL, that's the reason why Christian
has to make use of the Ecore::EPackage, to enclose the types in the
oclstdlib ...so confusing ...Like the "ecore" file used to represent it...
And obviously, creating a QVTo::Library for the OCL one, doesn't make
too much sense...
I'll be working on it (the eqvtostdlib model) and more derived problems
(f.e. integrating new stdlib extensions with the OCLparser), I hope that
with a good patch these issues get clearer...
Regards,
Adolfo.
Radek Dvorak escribió:
> Hi Adolfo,
>
> This extension point is a legacy way of registering native operations
> which came from the
> original Borland QVT implementation.
> Currently, our QVTO Standard library uses the same mechanism as MDT OCL
> for operation
> call dispatching, the library model is generated on they fly and is
> incomplete.
>
> Surely, having the complete QVT StdLib as a model is neccessary and I'm
> currently making changes in this
> direction.
> Conceptually, I think it would reasonable to achieve the following:
>
> 1) the user can write QVT library concrete syntax as black-box library,
> providing headers for operations, etc.
> ---parse ---> AST Model,
>
> 2) AST Model --transform--> GenModel, GenModel --generate--> Java source
> code
> - there could be a specific QVT gen-model, but I also think that
> annotated ecore and corresponding gen models could be used too,
> to leverage existing functionality for generation + merge
>
> 3) extension point - resolving the library impl for a given QVT source
> file or AST model, loading.
> - includes dispatching the AST call to the black-box implementation
> -> basically, there could be arbitrary structure of the java impl
> that might be hooked into the
> QVT engine by a common API, which would be fairly simple in this
> case.
>
> QVT StdLib, might be treated as any other blackbox library, and have its
> java implementation generated
> -> empty operation skeletons initially, like with EMF.
>
> As for the "extension" of OCL Standard library, for the beginning I
> would be happy to reference it
> just as any model, which is currently possible.
> I think, the term "extends" is quite bold in this context, and to me,
> the spec is not very convincing
> there should be really an OCL Library (QVToperational::Library) instance
> of it and "extends" relationship
> in terms of QVT. /*May be I have overlooked something there ;-) */
>
> Also, IMO, the model of OCL Standard Library pretty belongs to the scope
> of OCL spec and I would not
> expect it to conform to QVTO metamodel.
>
> Regards,
> /Radek
>
>
>
> On Wed, 26 Mar 2008 13:54:32 +0100, Adolfo Sánchez-Barbudo Herrera
> <adolfosbh@opencanarias.com> wrote:
>
>> Hi Alex,
>>
>> This seems to be an interesting way to create new operations for ocl
>> types or even, for new types. I suppose that you support
>> QVToStandardLibrary using this kind of mechanisms. Perhaps "split" is
>> a commented operation since it doesn't take part in the QVto Standard Li
>> brary...
>>
>> Anyway, specification talks about the existence of a QVTo Standard
>> Library (an instance of QVToperational::Library called StdLib) which
>> should contain the QVTo specific Types, and the type extensions of the
>> OclTypes.
>>
>> Ideally, this QVTo standard library could be persisted as a model, and
>> any QVToperational model should be able to refer to the Standrad
>> Library types, operations, etc, in the same way that OCLExpressions
>> refers to its OCL Standard Library types and operations. Besides, the
>> QVToStandardLibrary should pretentiously "extend" the
>> OCLStandardLibrary one (as the specification says).
>>
>> Actually, the oclStandardLibrary is not extensible with the actual
>> MDT-OCL implementation, since the implementation of the ocl Types are
>> coupled with the internal OclStandardLibrary implementation. I'm
>> working with Christian to solve this problem, and I have found an
>> "smart" solution which I have to contrast with him. I'm trying to find
>> more alternative solutions to this problem, since it will probably
>> involve additions to the actual API. We should lead this resolution to
>> the best one...
>>
>> Perhaps the use of this libraries extension points, could be thought
>> as the registration of the standard library, although I think that, at
>> least, the QVToStandardLibrary should be treated as a true model...
>>
>> Best Regards,
>> Adolfo.
>>
>> Alexander Igdalov escribió:
>>> Hi Juan,
>>> It is possible to add custom libraries to QVTO. You can use the
>>> extract from our Together documentation below. It is slightly out of
>>> date, so you may use
>>> org.eclipse.m2m.qvt.oml.ocl.emf.libraries.StringLibrary as an example.
>>> ========================
>>> QVT extensively uses OCL, adding a "write" capability to this
>>> "read-only" language through a number of special constructs. These
>>> QVT-specific constructs are described below.
>>> QVT implementation allows to call Java methods from within QVT
>>> sources. The mechanism used is identical to the one used for calling
>>> Java methods from OCL code. It allows to view specially written
>>> methods of a Java class as QVT operations.
>>> Let's consider a simple example of defining a new dumpErr operation
>>> with the following signature: OclAny::dumpErr(in prefix: String):
>>> OclAny. This operation prints the string representation of self,
>>> prepended by the prefix to a standard error, and returns self as the
>>> result.
>>> Note: The context parameter self is passed as the first parameter of
>>> the dumpErr operation. For OclVoid context, this parameter is omitted.
>>> First, we need a Java class implementing the operation:
>>> package qvtlib;
>>> public class SampleLibrary {
>>> public Object dumpErr(Object self, String prefix) {
>>> System.err.println(prefix + self);
>>> return self;
>>> }
>>> public static class Metainfo {
>>> private static final String[] DUMP_ERR = new String[] {
>>> "OclAny", "String", "OclAny" };
>>> public static String[] dumpErr(Object self, String prefix)
>>> {
>>> return DUMP_ERR;
>>> }
>>> }
>>> }
>>> Note that the context parameter self is passed as the first
>>> parameter of the dumpErr operation. In case of OclVoid context, this
>>> parameter is omitted.
>>> Static Metainfo class provides information on the signatures of the
>>> exported operations. Each exported operation should provide
>>> metainformation through the static method of this class. The method
>>> should have the same signature as the operation being described, and
>>> the String[] return type. The returned array should contain OCL type
>>> names and is interpreted as follows.
>>> array[0] -- context type
>>> array[1]..array[array.length-2] -- parameter type(s)
>>> array[array.length-1] -- return type
>>> SampleLibrary class must reside in the Eclipse plug-in which should
>>> also provide a org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension:
>>> <extension point="org.eclipse.m2m.qvt.oml.ocl.emf.libraries">
>>> <library class="qvtlib.SampleLibrary"
>>> id="qvtlib.SampleLibrary">
>>> <inMetamodel
>>> uri="http://www.eclipse.org/emf/2002/Ecore"/>
>>> <outMetamodel
>>> uri="http://www.eclipse.org/emf/2002/Ecore"/>
>>> </library>
>>> </extension>
>>> Extension specifies a library id (qvtlib.SampleLibrary), and,
>>> optionally, metamodels required by the library
>>> (http://www.eclipse.org/emf/2002/Ecore in our case).
>>> When the plug-in is deployed and available to the Workbench, the
>>> qvtlib.SampleLibrary library becomes available to QVT transformations
>>> and OCL scripts. It can be used with any QVT transformation whose
>>> transformation project has a dependency on the library plug-in. For
>>> example:
>>> transformation Ecore_To_Ecore;
>>> import library qvtlib.SampleLibrary;
>>> metamodel 'http://www.eclipse.org/emf/2002/Ecore';
>>> query dump(in model: ecore::EPackage): OclAny {
>>> model.dumpErr('model: ');
>>> }
>>> The above dumpErr call will be converted to the following Java code:
>>> new qvtlib.SampleLibrary().dumpErr(model, "model: "));
>>> ==========================
>>> Interestingly, StringLibrary has had split-operations that you need.
>>> For some reason, they were commented out and became unavailable. I've
>>> just committed split operation support and you can download QVTO
>>> sources (I hope downloading org.eclipse.m2m.qvt.oml.ocl.emf.libraries
>>> plugin is enough) to have them right away. An appropriate integration
>>> build will be published ASAP.
>>> Cheers,
>>> Alex.
>>> Juan Jose Cadavid G wrote:
>>>> Hello guys,
>>>>
>>>> It's me again. I'm not sure if this the right place to ask, but for
>>>> my transformation I have a comma-separated string and I need to
>>>> split it. From the OCL spec, I can see that the operations
>>>> supported by the String datatype are size(), concat(), substring(),
>>>> toInteger() and toReal(), but there's no split() operation. Is there
>>>> a way to extend the OCL or QVTO plug-in to add new operations to the
>>>> String datatype? I know you rely on the OCL plugin of the MDT
>>>> project, but I also saw you guys kind of add custom code to it,
>>>> since there's a plugin called org.eclipse.m2m.qvt.oml.ocl and others
>>>> like that.
>>>>
>>>> Can you give me the steps to follow? I know this is a lot of work
>>>> and I have to read a lot, but can you point me in the right direction?
>>>>
>>>> Thanks again ;)
>>>>
>>>> -Juan
>>>>
>
>
>
|
|
|
| Re: [QVTO] Adding custom operations for primitive data types [message #78115 is a reply to message #77426] |
Wed, 02 April 2008 01:00 |
|
Hi Alex,
Thanks a lot for your help and the documentation! However, I haven't
managed to make it work :(
First of all, I made a checkout of the
org.eclipse.m2m.qvt.oml.ocl.emf.libraries as you told me, and realized
that split() as well as other helpful operations were available there,
along with the required metadata according to the documentation. I packed
the plugin and used it to replace the old one in my Eclipse installation,
but I when trying to use the split(String) operation in my transformation
(say, myString.split(' ')) still got "Cannot find operation
(split(String)) for the type (String)" in the Problems view.
So, I went to read carefully the documentation again regarding where the
library has to be located. It says "SampleLibrary class must reside in the
Eclipse plug-in which should also provide a
org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension". Since StringLibrary
is contained in the plugin with that same name, I checked its plugin.xml
and realized it actually has an extension, but to the point
"org.eclipse.m2m.qvt.oml.ocl.libraries", which is different to the one
referred in the documentation. Is everything correct here? I tried adding
the "org.eclipse.m2m.qvt.oml.ocl.emf.libraries" extension, but the
manifest points an error saying that this extension point doesn't exist.
I also read on the documentation that any library, after being declared in
the org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension, "can be used with
any QVT transformation whose transformation project has a dependency on
the library plug-in". However, I also tried that... creating a
transformation project as a plug-in project and adding the
org.eclipse.m2m.qvt.oml.ocl.emf.libraries as a dependecy, but still the
same parse error.
I'd be extremely thankful if you guys can help me. Maybe now this is just
for a split() operation, but I found other string operations that can be
really helpful as well as other regarding EMF models (in EmfToolsLibrary),
and the big plus would be a mechanism for users to add their custom
operations implemented in Java where OCL would make it really complicated.
Thanks a lot guys!
-Juan
|
|
|
| Re: [QVTO] Adding custom operations for primitive data types [message #78161 is a reply to message #78115] |
Wed, 02 April 2008 12:36 |
| Eclipse User |
|
|
|
Originally posted by: Alexander.Igdalov.borland.com
Hi Juan,
Sorry for having referred to a wrong extension point name. In fact, one
should use "org.eclipse.m2m.qvt.oml.ocl.libraries" for registering QVTO
extension libraries.
To use the recently added split operations you need to have the updated
org.eclipse.m2m.qvt.oml.ocl.emf.libraries plugin in your target platform
and also to import the Strings library into your QVTO script.
Here follows a brief sample:
transformation Ecore_To_Uml(in dummy : ECORE, out ECORE);
import library Strings;
modeltype ECORE uses ecore('http://www.eclipse.org/emf/2002/Ecore');
mapping main(in model : EPackage) : EPackage {
init {
var eee : Sequence(String) := 'boo:and:foo'.split(':');
var e2 := eee->at(2); -- turns 'and' in runtime
}
}
HTH,
Alex.
Juan Jose Cadavid G wrote:
> Hi Alex,
>
> Thanks a lot for your help and the documentation! However, I haven't
> managed to make it work :(
>
> First of all, I made a checkout of the
> org.eclipse.m2m.qvt.oml.ocl.emf.libraries as you told me, and realized
> that split() as well as other helpful operations were available there,
> along with the required metadata according to the documentation. I
> packed the plugin and used it to replace the old one in my Eclipse
> installation, but I when trying to use the split(String) operation in my
> transformation (say, myString.split(' ')) still got "Cannot find
> operation (split(String)) for the type (String)" in the Problems view.
> So, I went to read carefully the documentation again regarding where the
> library has to be located. It says "SampleLibrary class must reside in
> the Eclipse plug-in which should also provide a
> org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension". Since
> StringLibrary is contained in the plugin with that same name, I checked
> its plugin.xml and realized it actually has an extension, but to the
> point "org.eclipse.m2m.qvt.oml.ocl.libraries", which is different to the
> one referred in the documentation. Is everything correct here? I tried
> adding the "org.eclipse.m2m.qvt.oml.ocl.emf.libraries" extension, but
> the manifest points an error saying that this extension point doesn't
> exist.
>
> I also read on the documentation that any library, after being declared
> in the org.eclipse.m2m.qvt.oml.ocl.emf.libraries extension, "can be used
> with any QVT transformation whose transformation project has a
> dependency on the library plug-in". However, I also tried that...
> creating a transformation project as a plug-in project and adding the
> org.eclipse.m2m.qvt.oml.ocl.emf.libraries as a dependecy, but still the
> same parse error.
>
> I'd be extremely thankful if you guys can help me. Maybe now this is
> just for a split() operation, but I found other string operations that
> can be really helpful as well as other regarding EMF models (in
> EmfToolsLibrary), and the big plus would be a mechanism for users to add
> their custom operations implemented in Java where OCL would make it
> really complicated.
>
> Thanks a lot guys!
>
> -Juan
>
|
|
| | |
Goto Forum:
Current Time: Fri Apr 19 00:16:42 GMT 2024
Powered by FUDForum. Page generated in 0.02678 seconds |
] 
Search
Help
Register
Login
Home
