Home » Modeling » OCL » extending the OCL parser and evaluation
| extending the OCL parser and evaluation [message #369136] |
Tue, 28 July 2009 20:04  |
 Elio Damaggio
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I am new to both OCL and this specific parser/interpreter so please
forgive me if I ask trivial questions.
I am trying to extend/modify the OCL parser/interpreter to support some
additional features:
1) some additional static operations
2) the Date datatype (with some additional operations on the string type
to act as constructors)
3) an assignment construct that assigns the result of an oclexpression to
a field or adds it to a collection in a specified way ( beginning or end,
flattened or not )
I have looked at the internal code of the parser and right now I have a
superficial knowledge of how the grammars, CST, AST are built and
structured.
I would be very grateful to anybody who could provide me some hints on
what is the best way to implement the above mentioned changes.
Last two things to say, first I am not familiar with the Ecore model so
there might be some easy way using those features that I cannot see.
Second, the whole thing will interface with a homegrown model/instance
memory representation ( not Ecore, not UML ), I could try to push Ecore,
but only if it saved implementation time (or I could code a
translation...).
Thanks in advance for anybody who will take some time to answer...
Elio Damaggio
|
|
|
| Re: extending the OCL parser and evaluation [message #371433 is a reply to message #369136] |
Wed, 29 July 2009 05:45  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Elio
The OCL parser was generalised in 1.20. and 1.3.0 to support extended
languages such as QVT. Even the OCL implementation treats itself as an
extension of EssentialOCL, so you may look at the EssentialOCL and
OCLParser grammars as examples of extension. You may look at
org.eclipse.qvt.declarative.parser.qvtcore or qvtrelation for more
substatial examples involving a form of 'assignment'.
[See for instance
org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.ecli pse.qvt.declarative.parser.qvtcore
in /cvsroot/modeling on dev.eclipse.org]
Any Java datatype can be used in your models by declaring it as the
instance type of an EDataType for your Ecore model.
Regards
Ed Willink
Elio Damaggio wrote:
> Hi all,
>
> I am new to both OCL and this specific parser/interpreter so please
> forgive me if I ask trivial questions.
>
> I am trying to extend/modify the OCL parser/interpreter to support some
> additional features:
>
> 1) some additional static operations
> 2) the Date datatype (with some additional operations on the string type
> to act as constructors)
> 3) an assignment construct that assigns the result of an oclexpression
> to a field or adds it to a collection in a specified way ( beginning or
> end, flattened or not )
>
> I have looked at the internal code of the parser and right now I have a
> superficial knowledge of how the grammars, CST, AST are built and
> structured.
>
> I would be very grateful to anybody who could provide me some hints on
> what is the best way to implement the above mentioned changes.
> Last two things to say, first I am not familiar with the Ecore model so
> there might be some easy way using those features that I cannot see.
> Second, the whole thing will interface with a homegrown model/instance
> memory representation ( not Ecore, not UML ), I could try to push Ecore,
> but only if it saved implementation time (or I could code a
> translation...).
>
> Thanks in advance for anybody who will take some time to answer...
>
> Elio Damaggio
>
|
|
|
| Re: extending the OCL parser and evaluation [message #373294 is a reply to message #369136] |
Wed, 29 July 2009 13:39 |
Eclipse User |
|
|
|
Originally posted by: Alexander.Igdalov.borland.com
Hi Elio,
Have you considered using QVT, e.g. Operational QVT? Being an extension
of OCL, QVTO has it all: adding new operations, new types and
assignments to modify or create new models.
See http://www.eclipse.org/m2m/ .
HTH,
Alex.
Elio Damaggio wrote:
> Hi all,
>
> I am new to both OCL and this specific parser/interpreter so please
> forgive me if I ask trivial questions.
>
> I am trying to extend/modify the OCL parser/interpreter to support some
> additional features:
>
> 1) some additional static operations
> 2) the Date datatype (with some additional operations on the string type
> to act as constructors)
> 3) an assignment construct that assigns the result of an oclexpression
> to a field or adds it to a collection in a specified way ( beginning or
> end, flattened or not )
>
> I have looked at the internal code of the parser and right now I have a
> superficial knowledge of how the grammars, CST, AST are built and
> structured.
>
> I would be very grateful to anybody who could provide me some hints on
> what is the best way to implement the above mentioned changes.
> Last two things to say, first I am not familiar with the Ecore model so
> there might be some easy way using those features that I cannot see.
> Second, the whole thing will interface with a homegrown model/instance
> memory representation ( not Ecore, not UML ), I could try to push Ecore,
> but only if it saved implementation time (or I could code a
> translation...).
>
> Thanks in advance for anybody who will take some time to answer...
>
> Elio Damaggio
>
|
|
|
| Re: extending the OCL parser and evaluation [message #435573 is a reply to message #371433] |
Thu, 30 July 2009 21:05 |
Elio Damaggio
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
I was able to reuse the EssentialOCL grammar and successfully parsing a
CST.
Since the application I have to interface with does not use Ecore, I was
wondering what is the best course of action.
I know that both the parser and the evaluator are generic w.r.t. Ecore and
UML, but the only examples I found simply extend the Ecore Environment.
I do not have a clear understanding of how to use a third metamodel for
the parsing and the evaluation.
Could you help me with that? Or point to some resource I can use?
Also, is it possible to define/access static operations of classes?
Thank you for your help,
Ed Willink wrote:
> Hi Elio
> The OCL parser was generalised in 1.20. and 1.3.0 to support extended
> languages such as QVT. Even the OCL implementation treats itself as an
> extension of EssentialOCL, so you may look at the EssentialOCL and
> OCLParser grammars as examples of extension. You may look at
> org.eclipse.qvt.declarative.parser.qvtcore or qvtrelation for more
> substatial examples involving a form of 'assignment'.
> [See for instance
>
org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.ecli pse.qvt.declarative.parser.qvtcore
> in /cvsroot/modeling on dev.eclipse.org]
> Any Java datatype can be used in your models by declaring it as the
> instance type of an EDataType for your Ecore model.
> Regards
> Ed Willink
> Elio Damaggio wrote:
>> Hi all,
>>
>> I am new to both OCL and this specific parser/interpreter so please
>> forgive me if I ask trivial questions.
>>
>> I am trying to extend/modify the OCL parser/interpreter to support some
>> additional features:
>>
>> 1) some additional static operations
>> 2) the Date datatype (with some additional operations on the string type
>> to act as constructors)
>> 3) an assignment construct that assigns the result of an oclexpression
>> to a field or adds it to a collection in a specified way ( beginning or
>> end, flattened or not )
>>
>> I have looked at the internal code of the parser and right now I have a
>> superficial knowledge of how the grammars, CST, AST are built and
>> structured.
>>
>> I would be very grateful to anybody who could provide me some hints on
>> what is the best way to implement the above mentioned changes.
>> Last two things to say, first I am not familiar with the Ecore model so
>> there might be some easy way using those features that I cannot see.
>> Second, the whole thing will interface with a homegrown model/instance
>> memory representation ( not Ecore, not UML ), I could try to push Ecore,
>> but only if it saved implementation time (or I could code a
>> translation...).
>>
>> Thanks in advance for anybody who will take some time to answer...
>>
>> Elio Damaggio
>>
|
|
|
| Re: extending the OCL parser and evaluation [message #438962 is a reply to message #435573] |
Fri, 31 July 2009 05:23 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Elio
All the QVT Declarative material currently extends the Ecore
Environment. Yet to be committed changes genmeralise that to Ecore or
UML but merit an API change to the OCL Environment. This will available
for Helios, but I cannot give a firmer timescale.
The OCL 2.1 RTF has introduced "static". I anticipate implementing it
quite soon.
Use of a third meta-model should be possible, though you will probably
find that it takes quite some time. You need to revise/generate a
replacement for all of the org.eclipse.ocl.uml plugin. I'm currently
revising the JUnit tests structure to support sharing/another metamodel.
Today you would clone org.eclipse.ocl.uml.tests. I would strongly
recommend reconsidering why you cannot use either the Ecore or UML bindings.
Regards
Ed Willink
Elio Damaggio wrote:
> Hi Ed,
>
> I was able to reuse the EssentialOCL grammar and successfully parsing a
> CST.
> Since the application I have to interface with does not use Ecore, I was
> wondering what is the best course of action.
>
> I know that both the parser and the evaluator are generic w.r.t. Ecore
> and UML, but the only examples I found simply extend the Ecore Environment.
> I do not have a clear understanding of how to use a third metamodel for
> the parsing and the evaluation.
> Could you help me with that? Or point to some resource I can use?
>
> Also, is it possible to define/access static operations of classes?
>
> Thank you for your help,
>
> Ed Willink wrote:
>
>> Hi Elio
>
>> The OCL parser was generalised in 1.20. and 1.3.0 to support extended
>> languages such as QVT. Even the OCL implementation treats itself as an
>> extension of EssentialOCL, so you may look at the EssentialOCL and
>> OCLParser grammars as examples of extension. You may look at
>> org.eclipse.qvt.declarative.parser.qvtcore or qvtrelation for more
>> substatial examples involving a form of 'assignment'.
>
>> [See for instance
> org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.ecli pse.qvt.declarative.parser.qvtcore
>
>> in /cvsroot/modeling on dev.eclipse.org]
>
>> Any Java datatype can be used in your models by declaring it as the
>> instance type of an EDataType for your Ecore model.
>
>> Regards
>
>> Ed Willink
>
>> Elio Damaggio wrote:
>>> Hi all,
>>>
>>> I am new to both OCL and this specific parser/interpreter so please
>>> forgive me if I ask trivial questions.
>>>
>>> I am trying to extend/modify the OCL parser/interpreter to support
>>> some additional features:
>>>
>>> 1) some additional static operations
>>> 2) the Date datatype (with some additional operations on the string
>>> type to act as constructors)
>>> 3) an assignment construct that assigns the result of an
>>> oclexpression to a field or adds it to a collection in a specified
>>> way ( beginning or end, flattened or not )
>>>
>>> I have looked at the internal code of the parser and right now I have
>>> a superficial knowledge of how the grammars, CST, AST are built and
>>> structured.
>>>
>>> I would be very grateful to anybody who could provide me some hints
>>> on what is the best way to implement the above mentioned changes.
>>> Last two things to say, first I am not familiar with the Ecore model
>>> so there might be some easy way using those features that I cannot see.
>>> Second, the whole thing will interface with a homegrown
>>> model/instance memory representation ( not Ecore, not UML ), I could
>>> try to push Ecore, but only if it saved implementation time (or I
>>> could code a translation...).
>>>
>>> Thanks in advance for anybody who will take some time to answer...
>>>
>>> Elio Damaggio
>>>
>
>
|
|
|
| Re: extending the OCL parser and evaluation [message #440256 is a reply to message #438962] |
Fri, 31 July 2009 07:56 |
| Eclipse User |
|
|
|
Originally posted by: Alexander.Igdalov.borland.com
Hi Ed and Elio,
>> I do not have a clear understanding of how to use a third metamodel
>> for the parsing and the evaluation.
You can consider creating a wrapping EMF model delegating calls to your
proprietary model.
Cheers,
Alex.
Ed Willink wrote:
> Hi Elio
>
> All the QVT Declarative material currently extends the Ecore
> Environment. Yet to be committed changes genmeralise that to Ecore or
> UML but merit an API change to the OCL Environment. This will available
> for Helios, but I cannot give a firmer timescale.
>
> The OCL 2.1 RTF has introduced "static". I anticipate implementing it
> quite soon.
>
> Use of a third meta-model should be possible, though you will probably
> find that it takes quite some time. You need to revise/generate a
> replacement for all of the org.eclipse.ocl.uml plugin. I'm currently
> revising the JUnit tests structure to support sharing/another metamodel.
> Today you would clone org.eclipse.ocl.uml.tests. I would strongly
> recommend reconsidering why you cannot use either the Ecore or UML
> bindings.
>
> Regards
>
> Ed Willink
>
> Elio Damaggio wrote:
>> Hi Ed,
>>
>> I was able to reuse the EssentialOCL grammar and successfully parsing
>> a CST.
>> Since the application I have to interface with does not use Ecore, I
>> was wondering what is the best course of action.
>>
>> I know that both the parser and the evaluator are generic w.r.t. Ecore
>> and UML, but the only examples I found simply extend the Ecore
>> Environment.
>> I do not have a clear understanding of how to use a third metamodel
>> for the parsing and the evaluation.
>> Could you help me with that? Or point to some resource I can use?
>>
>> Also, is it possible to define/access static operations of classes?
>>
>> Thank you for your help,
>>
>> Ed Willink wrote:
>>
>>> Hi Elio
>>
>>> The OCL parser was generalised in 1.20. and 1.3.0 to support extended
>>> languages such as QVT. Even the OCL implementation treats itself as
>>> an extension of EssentialOCL, so you may look at the EssentialOCL and
>>> OCLParser grammars as examples of extension. You may look at
>>> org.eclipse.qvt.declarative.parser.qvtcore or qvtrelation for more
>>> substatial examples involving a form of 'assignment'.
>>
>>> [See for instance
>> org.eclipse.m2m/org.eclipse.qvt.declarative/plugins/org.ecli pse.qvt.declarative.parser.qvtcore
>>
>>> in /cvsroot/modeling on dev.eclipse.org]
>>
>>> Any Java datatype can be used in your models by declaring it as the
>>> instance type of an EDataType for your Ecore model.
>>
>>> Regards
>>
>>> Ed Willink
>>
>>> Elio Damaggio wrote:
>>>> Hi all,
>>>>
>>>> I am new to both OCL and this specific parser/interpreter so please
>>>> forgive me if I ask trivial questions.
>>>>
>>>> I am trying to extend/modify the OCL parser/interpreter to support
>>>> some additional features:
>>>>
>>>> 1) some additional static operations
>>>> 2) the Date datatype (with some additional operations on the string
>>>> type to act as constructors)
>>>> 3) an assignment construct that assigns the result of an
>>>> oclexpression to a field or adds it to a collection in a specified
>>>> way ( beginning or end, flattened or not )
>>>>
>>>> I have looked at the internal code of the parser and right now I
>>>> have a superficial knowledge of how the grammars, CST, AST are built
>>>> and structured.
>>>>
>>>> I would be very grateful to anybody who could provide me some hints
>>>> on what is the best way to implement the above mentioned changes.
>>>> Last two things to say, first I am not familiar with the Ecore model
>>>> so there might be some easy way using those features that I cannot see.
>>>> Second, the whole thing will interface with a homegrown
>>>> model/instance memory representation ( not Ecore, not UML ), I could
>>>> try to push Ecore, but only if it saved implementation time (or I
>>>> could code a translation...).
>>>>
>>>> Thanks in advance for anybody who will take some time to answer...
>>>>
>>>> Elio Damaggio
>>>>
>>
>>
|
|
| | | |
| Re: extending the OCL parser and evaluation [message #468256 is a reply to message #468214] |
Tue, 04 August 2009 17:44 |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Elio
Forgive my ignorance, but I'm unaware of the Apache Tuscany project. A
quick Google shows that it is a large professional Open Source project
with regular nightly builds. It therefore seems VERY unlikely that it
has a 3 year old version of Ecore as a mandatory prerequisite. I suggest
that you investigate your statement "it does not seem to work with ecore
> 2.2". I think you will find a trivial problem, but of course only
trivial in hindsight.
Otherwise you have a variety of horrible alternatives:
Develop an EMF variant with ongoing support for 2.2 bnehaviour.
Develop an OCL variant for Ecore 2.2 (MDT-OCL 1.0 might be a starting
point).
Develop a Tuscany variant that supports Ecore 2.5.
Develop a bridge.
Any of which will be a maintenance nightmare. Find the trivial problem.
Regards
Ed Willink
Elio Damaggio wrote:
> Hi Ed,
>
> well, here is my situation:
> I have to integrate a modified version of the OCL parser into an
> application that uses Apache Tuscany SDO implementation (which uses
> ecore 2.2 and it does not seem to work with ecore > 2.2).
>
> Are you suggesting that I modify the old OCL parser that used ecore 2.2?
> Does there exist one?
>
> Thanks,
>
> Elio
>
> Ed Willink wrote:
>
>> Hi Elio
>
>> > do you think there is someway I can modify the ocl evaluation in order
>> > that it does not use the latest features Ecore > 2.2?
>
>> It's only software; of course it's possible; just incredibly difficult.
>
>> > Any better idea?
>
>> Yes. Find out where the true problem is coming in.
>
>> Ecore is upward compatible, so you can quite happily use old Ecore
>> models with a later Ecore release.
>
>> You appear to have a mishmash of Eclipse contributions, which ought to
>> give you some warnings about version dependencies. If you're using
>> plugins you can invoke Validate on the Plugin page of the launcher to
>> check that they're all consistent.
>
>> It's possible that you've just got a bad build state through loading
>> replacement plugins. Try a clean and rebuild. Try a close all projects
>> and reopen. Try an Eclipse restart. (Incremental builds are not always
>> correct when Eclipse has more than one choice of org.eclipse.xxxx and
>> the choice preference changes a little.)
>
>> Overall, I would very strongly recommend that you establish why you
>> cannot use all plugins from the same Eclipse vintage.
>
>> 2.2/2.3/2.4/2.5 Ecore are fundamentally very similar.
>> ?/?/1.2/1.3 MDT-OCL are fairly similar
>> 1.0/1.1 MDT-OCL may lack some functionality.
>
>> Regards
>
>> Ed Willink
>
>> Elio Damaggio wrote:
>>> Hi!
>>>
>>> I found out that the model I am using is the one used in Tuscany SDO
>>> implementation.
>>> It turns out this IS Ecore. However, I have a big problem.
>>> It actually uses Ecore 2.2 (pre generics).
>>> It does not seem compatible with any later version.
>>>
>>> Right now I get this exception:
>>>
>>> java.lang.NoSuchMethodError:
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.addEType Parameter(Lorg/eclipse/emf/ecore/EClassifier;Ljava/lang/Stri ng;)Lorg/eclipse/emf/ecore/ETypeParameter;
>
>>>
>>> at
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.initiali zePackageContentsGen(UtilitiesPackageImpl.java:468)
>
>>>
>>> at
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.initiali zePackageContents(UtilitiesPackageImpl.java:440)
>
>>>
>>> at
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.init(Uti litiesPackageImpl.java:176)
>
>>>
>>> at
> org.eclipse.ocl.utilities.UtilitiesPackage.<clinit>(UtilitiesPackage.java:85)
>
>>>
>>> at
>>> org.eclipse.ocl.types.impl.TypesPackageImpl.init(TypesPackag eImpl.java:206)
>>>
>>> at org.eclipse.ocl.types.TypesPackage.<clinit>(TypesPackage.java:85)
>>> at
> org.eclipse.ocl.expressions.impl.ExpressionsPackageImpl.init (ExpressionsPackageImpl.java:420)
>
>>>
>>> at
> org.eclipse.ocl.expressions.ExpressionsPackage.<clinit>(ExpressionsPackage.java:87)
>
>>>
>>> at
>>> org.eclipse.ocl.ecore.EcoreEnvironment.<clinit>(EcoreEnvironment.java:91)
>>>
>>> at
> org.eclipse.ocl.ecore.EcoreEnvironmentFactory.createEnvironm ent(EcoreEnvironmentFactory.java:83)
>
>>>
>>> at org.eclipse.ocl.OCL.<init>(OCL.java:101)
>>>
>>> do you think there is someway I can modify the ocl evaluation in
>>> order that it does not use the latest features Ecore > 2.2?
>>> Any better idea?
>>>
>>> Elio
>>>
>
>
|
|
|
| Re: extending the OCL parser and evaluation [message #482955 is a reply to message #468256] |
Fri, 28 August 2009 16:42 |
Elio Damaggio
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Hi Ed,
what I ended up doing was to regenerate the code of Tuscany SDO using EMF
2.5.
There are some little glitches in features I do not use (I am in contact
with the Tuscany guys to solve those, though).
I think there was no trivial problem... :(
Anyway, thanks for your help.
Elio
Ed Willink wrote:
> Hi Elio
> Forgive my ignorance, but I'm unaware of the Apache Tuscany project. A
> quick Google shows that it is a large professional Open Source project
> with regular nightly builds. It therefore seems VERY unlikely that it
> has a 3 year old version of Ecore as a mandatory prerequisite. I suggest
> that you investigate your statement "it does not seem to work with ecore
> > 2.2". I think you will find a trivial problem, but of course only
> trivial in hindsight.
> Otherwise you have a variety of horrible alternatives:
> Develop an EMF variant with ongoing support for 2.2 bnehaviour.
> Develop an OCL variant for Ecore 2.2 (MDT-OCL 1.0 might be a starting
> point).
> Develop a Tuscany variant that supports Ecore 2.5.
> Develop a bridge.
> Any of which will be a maintenance nightmare. Find the trivial problem.
> Regards
> Ed Willink
> Elio Damaggio wrote:
>> Hi Ed,
>>
>> well, here is my situation:
>> I have to integrate a modified version of the OCL parser into an
>> application that uses Apache Tuscany SDO implementation (which uses
>> ecore 2.2 and it does not seem to work with ecore > 2.2).
>>
>> Are you suggesting that I modify the old OCL parser that used ecore 2.2?
>> Does there exist one?
>>
>> Thanks,
>>
>> Elio
>>
>> Ed Willink wrote:
>>
>>> Hi Elio
>>
>>> > do you think there is someway I can modify the ocl evaluation in order
>>> > that it does not use the latest features Ecore > 2.2?
>>
>>> It's only software; of course it's possible; just incredibly difficult.
>>
>>> > Any better idea?
>>
>>> Yes. Find out where the true problem is coming in.
>>
>>> Ecore is upward compatible, so you can quite happily use old Ecore
>>> models with a later Ecore release.
>>
>>> You appear to have a mishmash of Eclipse contributions, which ought to
>>> give you some warnings about version dependencies. If you're using
>>> plugins you can invoke Validate on the Plugin page of the launcher to
>>> check that they're all consistent.
>>
>>> It's possible that you've just got a bad build state through loading
>>> replacement plugins. Try a clean and rebuild. Try a close all projects
>>> and reopen. Try an Eclipse restart. (Incremental builds are not always
>>> correct when Eclipse has more than one choice of org.eclipse.xxxx and
>>> the choice preference changes a little.)
>>
>>> Overall, I would very strongly recommend that you establish why you
>>> cannot use all plugins from the same Eclipse vintage.
>>
>>> 2.2/2.3/2.4/2.5 Ecore are fundamentally very similar.
>>> ?/?/1.2/1.3 MDT-OCL are fairly similar
>>> 1.0/1.1 MDT-OCL may lack some functionality.
>>
>>> Regards
>>
>>> Ed Willink
>>
>>> Elio Damaggio wrote:
>>>> Hi!
>>>>
>>>> I found out that the model I am using is the one used in Tuscany SDO
>>>> implementation.
>>>> It turns out this IS Ecore. However, I have a big problem.
>>>> It actually uses Ecore 2.2 (pre generics).
>>>> It does not seem compatible with any later version.
>>>>
>>>> Right now I get this exception:
>>>>
>>>> java.lang.NoSuchMethodError:
>>
org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.addEType Parameter(Lorg/eclipse/emf/ecore/EClassifier;Ljava/lang/Stri ng;)Lorg/eclipse/emf/ecore/ETypeParameter;
>>
>>>>
>>>> at
>>
org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.initiali zePackageContentsGen(UtilitiesPackageImpl.java:468)
>>
>>>>
>>>> at
>>
org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.initiali zePackageContents(UtilitiesPackageImpl.java:440)
>>
>>>>
>>>> at
>>
org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.init(Uti litiesPackageImpl.java:176)
>>
>>>>
>>>> at
>>
org.eclipse.ocl.utilities.UtilitiesPackage.<clinit>(UtilitiesPackage.java:85)
>>
>>>>
>>>> at
>>>>
org.eclipse.ocl.types.impl.TypesPackageImpl.init(TypesPackag eImpl.java:206)
>>>>
>>>> at org.eclipse.ocl.types.TypesPackage.<clinit>(TypesPackage.java:85)
>>>> at
>>
org.eclipse.ocl.expressions.impl.ExpressionsPackageImpl.init (ExpressionsPackageImpl.java:420)
>>
>>>>
>>>> at
>>
org.eclipse.ocl.expressions.ExpressionsPackage.<clinit>(ExpressionsPackage.java:87)
>>
>>>>
>>>> at
>>>> org.eclipse.ocl.ecore.EcoreEnvironment.<clinit>(EcoreEnvironment.java:91)
>>>>
>>>> at
>>
org.eclipse.ocl.ecore.EcoreEnvironmentFactory.createEnvironm ent(EcoreEnvironmentFactory.java:83)
>>
>>>>
>>>> at org.eclipse.ocl.OCL.<init>(OCL.java:101)
>>>>
>>>> do you think there is someway I can modify the ocl evaluation in
>>>> order that it does not use the latest features Ecore > 2.2?
>>>> Any better idea?
>>>>
>>>> Elio
>>>>
>>
>>
|
|
|
| Re: extending the OCL parser and evaluation [message #483017 is a reply to message #482955] |
Sat, 29 August 2009 11:30 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Guys,
It wouldn't surprise me in the least that Tuscany would be using a very
old version of EMF, i.e., a pre Java 5.0 version. I'm not even sure
which level of SDO is being implemented...
Elio Damaggio wrote:
> Hi Ed,
>
> what I ended up doing was to regenerate the code of Tuscany SDO using
> EMF 2.5.
> There are some little glitches in features I do not use (I am in
> contact with the Tuscany guys to solve those, though).
> I think there was no trivial problem... :(
> Anyway, thanks for your help.
>
> Elio
>
> Ed Willink wrote:
>
>> Hi Elio
>
>> Forgive my ignorance, but I'm unaware of the Apache Tuscany project.
>> A quick Google shows that it is a large professional Open Source
>> project with regular nightly builds. It therefore seems VERY unlikely
>> that it has a 3 year old version of Ecore as a mandatory
>> prerequisite. I suggest that you investigate your statement "it does
>> not seem to work with ecore > 2.2". I think you will find a trivial
>> problem, but of course only trivial in hindsight.
>
>> Otherwise you have a variety of horrible alternatives:
>
>> Develop an EMF variant with ongoing support for 2.2 bnehaviour.
>> Develop an OCL variant for Ecore 2.2 (MDT-OCL 1.0 might be a starting
>> point).
>> Develop a Tuscany variant that supports Ecore 2.5.
>> Develop a bridge.
>
>> Any of which will be a maintenance nightmare. Find the trivial problem.
>
>> Regards
>
>> Ed Willink
>
>
>> Elio Damaggio wrote:
>>> Hi Ed,
>>>
>>> well, here is my situation:
>>> I have to integrate a modified version of the OCL parser into an
>>> application that uses Apache Tuscany SDO implementation (which uses
>>> ecore 2.2 and it does not seem to work with ecore > 2.2).
>>>
>>> Are you suggesting that I modify the old OCL parser that used ecore
>>> 2.2?
>>> Does there exist one?
>>>
>>> Thanks,
>>>
>>> Elio
>>>
>>> Ed Willink wrote:
>>>
>>>> Hi Elio
>>>
>>>> > do you think there is someway I can modify the ocl evaluation in
>>>> order
>>>> > that it does not use the latest features Ecore > 2.2?
>>>
>>>> It's only software; of course it's possible; just incredibly
>>>> difficult.
>>>
>>>> > Any better idea?
>>>
>>>> Yes. Find out where the true problem is coming in.
>>>
>>>> Ecore is upward compatible, so you can quite happily use old Ecore
>>>> models with a later Ecore release.
>>>
>>>> You appear to have a mishmash of Eclipse contributions, which ought
>>>> to give you some warnings about version dependencies. If you're
>>>> using plugins you can invoke Validate on the Plugin page of the
>>>> launcher to check that they're all consistent.
>>>
>>>> It's possible that you've just got a bad build state through
>>>> loading replacement plugins. Try a clean and rebuild. Try a close
>>>> all projects
>>>> and reopen. Try an Eclipse restart. (Incremental builds are not always
>>>> correct when Eclipse has more than one choice of org.eclipse.xxxx and
>>>> the choice preference changes a little.)
>>>
>>>> Overall, I would very strongly recommend that you establish why you
>>>> cannot use all plugins from the same Eclipse vintage.
>>>
>>>> 2.2/2.3/2.4/2.5 Ecore are fundamentally very similar.
>>>> ?/?/1.2/1.3 MDT-OCL are fairly similar
>>>> 1.0/1.1 MDT-OCL may lack some functionality.
>>>
>>>> Regards
>>>
>>>> Ed Willink
>>>
>>>> Elio Damaggio wrote:
>>>>> Hi!
>>>>>
>>>>> I found out that the model I am using is the one used in Tuscany
>>>>> SDO implementation.
>>>>> It turns out this IS Ecore. However, I have a big problem.
>>>>> It actually uses Ecore 2.2 (pre generics).
>>>>> It does not seem compatible with any later version.
>>>>>
>>>>> Right now I get this exception:
>>>>>
>>>>> java.lang.NoSuchMethodError:
>>>
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.addEType Parameter(Lorg/eclipse/emf/ecore/EClassifier;Ljava/lang/Stri ng;)Lorg/eclipse/emf/ecore/ETypeParameter;
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.initiali zePackageContentsGen(UtilitiesPackageImpl.java:468)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.initiali zePackageContents(UtilitiesPackageImpl.java:440)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.ocl.utilities.impl.UtilitiesPackageImpl.init(Uti litiesPackageImpl.java:176)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.ocl.utilities.UtilitiesPackage.<clinit>(UtilitiesPackage.java:85)
>
>>>
>>>>>
>>>>> at
> org.eclipse.ocl.types.impl.TypesPackageImpl.init(TypesPackag eImpl.java:206)
>
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.types.TypesPackage.<clinit>(TypesPackage.java:85)
>>>>> at
>>>
> org.eclipse.ocl.expressions.impl.ExpressionsPackageImpl.init (ExpressionsPackageImpl.java:420)
>
>>>
>>>>>
>>>>> at
>>>
> org.eclipse.ocl.expressions.ExpressionsPackage.<clinit>(ExpressionsPackage.java:87)
>
>>>
>>>>>
>>>>> at
>>>>> org.eclipse.ocl.ecore.EcoreEnvironment.<clinit>(EcoreEnvironment.java:91)
>>>>>
>>>>> at
>>>
> org.eclipse.ocl.ecore.EcoreEnvironmentFactory.createEnvironm ent(EcoreEnvironmentFactory.java:83)
>
>>>
>>>>>
>>>>> at org.eclipse.ocl.OCL.<init>(OCL.java:101)
>>>>>
>>>>> do you think there is someway I can modify the ocl evaluation in
>>>>> order that it does not use the latest features Ecore > 2.2?
>>>>> Any better idea?
>>>>>
>>>>> Elio
>>>>>
>>>
>>>
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 06:01:25 GMT 2024
Powered by FUDForum. Page generated in 0.04123 seconds |
] 
Search
Help
Register
Login
Home
