Eclipse Community Forums: TMF (Xtext) » Xtext CDO integration.

Help

Home

Home » Modeling » TMF (Xtext) » Xtext CDO integration.

Show: Today's Messages :: Show Polls :: Message Navigator

Xtext CDO integration. [message #682154]

Fri, 10 June 2011 14:12

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Dear XText community,

We want to integrate xtext with a CDO Repository, for our expression DSL
grammar. This is roughly the intend in two working scenarios, and I
would like to ask, if the approach is correct, and we have no oversight,
on which xtext services, customization is necessary.

A) Editing the DSL.
-------------------

1) A global scope provider, with capabilities to resolve IScope for CDO
based resources allows us to create references in our expression DSL to
external model objects which reside in the CDO repository.

For this: I foresee, customizing the following services:

IGlobalScopeProvider
(Likely an adaptation of DefaultGlobalScopeProvider)

IQualifiedNameProvider
(Likely an adaptation of SimpleNameProvider).

IResourceServiceProvider
(An implementation which can deal with CDO URI).

IResourceDescriptions
(Perhaps not needed, if we can load our CDO resource in the
resourceset, we can use: ResourceSetBasedResourceDescriptions).

On the linking side, we foresee that the workspace builder would need to
be replaced / adapted aswell to load resources from the CDO Repo.
Perhaps we need to adapt the LazyLinker to deal with CDO proxies and
EPackage resolving:

IXtextBuilderParticipant, This I am not sure about. Do we need a
workspace builder at all when dealing with a CDO Repository? Our xtext
editor will be running in an RCP app. (Which has a workspace if needed).

B) Executing the DSL server side.
---------------------------------

1) Our DSL instance is stored as a String in our Domain (Non-Xtext model).
2) The grammar is de-serialized when needed, the Linker should kick-in
to link the references (Lazily?), if all are resolved. (CDO URI's will
be resolved).
3) The expression interpreter is called, with the valid grammar parse tree.

Thank You, Christophe

Report message to a moderator

Re: Xtext CDO integration. [message #682233 is a reply to message #682154]

Fri, 10 June 2011 16:54

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Hi Christophe,

That sounds very interesting. Have you considered the challenge that, AFAIK, the Xtext parser creates a *new* model with each pass rather than updating an existing one? That may not be what you want if your models are stored in a repository where *all* their elements have unique technical identifiers that other objects use as references.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Am 10.06.2011 16:12, schrieb Christophe Bouhier:
> Dear XText community,
>
> We want to integrate xtext with a CDO Repository, for our expression DSL grammar. This is roughly the intend in two working scenarios, and I would like to ask, if the approach is correct, and we have no oversight, on which xtext services, customization is necessary.
>
> A) Editing the DSL.
> -------------------
>
> 1) A global scope provider, with capabilities to resolve IScope for CDO based resources allows us to create references in our expression DSL to external model objects which reside in the CDO repository.
>
> For this: I foresee, customizing the following services:
>
> IGlobalScopeProvider
> (Likely an adaptation of DefaultGlobalScopeProvider)
>
> IQualifiedNameProvider
> (Likely an adaptation of SimpleNameProvider).
>
> IResourceServiceProvider
> (An implementation which can deal with CDO URI).
>
> IResourceDescriptions
> (Perhaps not needed, if we can load our CDO resource in the resourceset, we can use: ResourceSetBasedResourceDescriptions).
>
>
> On the linking side, we foresee that the workspace builder would need to be replaced / adapted aswell to load resources from the CDO Repo.
> Perhaps we need to adapt the LazyLinker to deal with CDO proxies and EPackage resolving:
>
>
> IXtextBuilderParticipant, This I am not sure about. Do we need a workspace builder at all when dealing with a CDO Repository? Our xtext editor will be running in an RCP app. (Which has a workspace if needed).
>
> B) Executing the DSL server side.
> ---------------------------------
>
> 1) Our DSL instance is stored as a String in our Domain (Non-Xtext model).
> 2) The grammar is de-serialized when needed, the Linker should kick-in to link the references (Lazily?), if all are resolved. (CDO URI's will be resolved).
> 3) The expression interpreter is called, with the valid grammar parse tree.
>
>
> Thank You, Christophe
>
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Re: Xtext CDO integration. [message #682313 is a reply to message #682233]

Fri, 10 June 2011 20:11

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Hi Eike,

Yes, interesting indeed, thanks for pointing this out, but do you mean
these object can't be resolved, or the fact, that it a process which
happens over and over again and will be heavy on the server side?

The alternative of course would be to keep the parsed and linked
expression model in CDO as well, which would avoid the de-serialization
and linking process, perhaps it's worthwhile investigating that
alternative as well.

If you get a chance, check out the Class LazyLinker in xtext 2.0

Cheers Christophe

On 10-06-11 18:54, Eike Stepper wrote:
> Hi Christophe,
>
> That sounds very interesting. Have you considered the challenge that,
> AFAIK, the Xtext parser creates a *new* model with each pass rather than
> updating an existing one? That may not be what you want if your models
> are stored in a repository where *all* their elements have unique
> technical identifiers that other objects use as references.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
> Am 10.06.2011 16:12, schrieb Christophe Bouhier:
>> Dear XText community,
>>
>> We want to integrate xtext with a CDO Repository, for our expression
>> DSL grammar. This is roughly the intend in two working scenarios, and
>> I would like to ask, if the approach is correct, and we have no
>> oversight, on which xtext services, customization is necessary.
>>
>> A) Editing the DSL.
>> -------------------
>>
>> 1) A global scope provider, with capabilities to resolve IScope for
>> CDO based resources allows us to create references in our expression
>> DSL to external model objects which reside in the CDO repository.
>>
>> For this: I foresee, customizing the following services:
>>
>> IGlobalScopeProvider
>> (Likely an adaptation of DefaultGlobalScopeProvider)
>>
>> IQualifiedNameProvider
>> (Likely an adaptation of SimpleNameProvider).
>>
>> IResourceServiceProvider
>> (An implementation which can deal with CDO URI).
>>
>> IResourceDescriptions
>> (Perhaps not needed, if we can load our CDO resource in the
>> resourceset, we can use: ResourceSetBasedResourceDescriptions).
>>
>>
>> On the linking side, we foresee that the workspace builder would need
>> to be replaced / adapted aswell to load resources from the CDO Repo.
>> Perhaps we need to adapt the LazyLinker to deal with CDO proxies and
>> EPackage resolving:
>>
>>
>> IXtextBuilderParticipant, This I am not sure about. Do we need a
>> workspace builder at all when dealing with a CDO Repository? Our xtext
>> editor will be running in an RCP app. (Which has a workspace if needed).
>>
>> B) Executing the DSL server side.
>> ---------------------------------
>>
>> 1) Our DSL instance is stored as a String in our Domain (Non-Xtext
>> model).
>> 2) The grammar is de-serialized when needed, the Linker should kick-in
>> to link the references (Lazily?), if all are resolved. (CDO URI's will
>> be resolved).
>> 3) The expression interpreter is called, with the valid grammar parse
>> tree.
>>
>>
>> Thank You, Christophe
>>
>>

Report message to a moderator

Re: Xtext CDO integration. [message #682322 is a reply to message #682233]

Fri, 10 June 2011 20:28

Ed Willink

Messages: 7655
Registered: July 2009

Senior Member

Hi Eike
> Have you considered the challenge that, AFAIK, the Xtext parser
> creates a *new* model with each pass rather than updating an existing
> one? That may not be what you want
Yes, It's a bit unpleasant. For the OCL editors I wanted to preserve the
option of ResourceSet/TransactionalEditDomain sharing and anyway had to
have distinct Concrete Sytntax and Abstract Syntax models, so although
the CS is regularly recreated, the afterLinking() mapping from CS to AS
re-uses the AS objects for the common cases of trivial deltas.

OCL's AS and CS have some structural differences and so are not directly
matchable, however a common hierarchical identifier, that I call a
moniker, can be provided. The moniker of a new CS element may therefore
be looked up to identify its old AS counterpart for reuse.

I cannot recommend this approach; debugging repeatability and uniqueness
of monikers and garbage collecting obsolete AS elements has proved very
troublesome.

Regards

Ed Willink

Report message to a moderator

Re: Xtext CDO integration. [message #684279 is a reply to message #682233]

Wed, 15 June 2011 10:34

Christophe Bouhier

Messages: 937
Registered: July 2009

Senior Member

Hi there,

Just to let people know, we managed to get the CDO integration with
xtext working without too much hassle. The following adaptations were
needed:

- Register CDOResourceServiceProvider with an extension like this:

<extension point="org.eclipse.xtext.protocol_resourceServiceProvider">
<resourceServiceProvider
class="xxx.ExecutableExtensionFactory:xxx.CDOResourceServiceProvider"
protocolName="cdo">
</resourceServiceProvider>
</extension>

The ServiceProvider, extends the DefaultResourceServiceProvider and
overrides: canHandle(URI uri) to return through on scheme "cdo"

- CDOGlobalScopeProvider

What it does, is feed a list of CDO type URI's which look like this
cdo://repo/"resource name"

further on, to build the scope we need an IResourceDescriptions. Our
version, gets the CDO URI, and connects to the CDO repo. The returned
CDO resource is fed to the created
CDOResourceServiceProvider.getResourceDescriptionManager.getResourceDescription(cdoResource).

We also needed to customize the name provider which is used in the
IDefaultResourceDescriptionStrategy, to make sure that our references
appear. (that is not specific to CDO).

Next: It would be nice to see, if reference indexes can be re-used in
the IResourceDescriptions from the CDO server side. Not sure what the
API for this is on CDO side...

Cheers Christophe

On 10-06-11 18:54, Eike Stepper wrote:
> Hi Christophe,
>
> That sounds very interesting. Have you considered the challenge that,
> AFAIK, the Xtext parser creates a *new* model with each pass rather than
> updating an existing one? That may not be what you want if your models
> are stored in a repository where *all* their elements have unique
> technical identifiers that other objects use as references.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>
> Am 10.06.2011 16:12, schrieb Christophe Bouhier:
>> Dear XText community,
>>
>> We want to integrate xtext with a CDO Repository, for our expression
>> DSL grammar. This is roughly the intend in two working scenarios, and
>> I would like to ask, if the approach is correct, and we have no
>> oversight, on which xtext services, customization is necessary.
>>
>> A) Editing the DSL.
>> -------------------
>>
>> 1) A global scope provider, with capabilities to resolve IScope for
>> CDO based resources allows us to create references in our expression
>> DSL to external model objects which reside in the CDO repository.
>>
>> For this: I foresee, customizing the following services:
>>
>> IGlobalScopeProvider
>> (Likely an adaptation of DefaultGlobalScopeProvider)
>>
>> IQualifiedNameProvider
>> (Likely an adaptation of SimpleNameProvider).
>>
>> IResourceServiceProvider
>> (An implementation which can deal with CDO URI).
>>
>> IResourceDescriptions
>> (Perhaps not needed, if we can load our CDO resource in the
>> resourceset, we can use: ResourceSetBasedResourceDescriptions).
>>
>>
>> On the linking side, we foresee that the workspace builder would need
>> to be replaced / adapted aswell to load resources from the CDO Repo.
>> Perhaps we need to adapt the LazyLinker to deal with CDO proxies and
>> EPackage resolving:
>>
>>
>> IXtextBuilderParticipant, This I am not sure about. Do we need a
>> workspace builder at all when dealing with a CDO Repository? Our xtext
>> editor will be running in an RCP app. (Which has a workspace if needed).
>>
>> B) Executing the DSL server side.
>> ---------------------------------
>>
>> 1) Our DSL instance is stored as a String in our Domain (Non-Xtext
>> model).
>> 2) The grammar is de-serialized when needed, the Linker should kick-in
>> to link the references (Lazily?), if all are resolved. (CDO URI's will
>> be resolved).
>> 3) The expression interpreter is called, with the valid grammar parse
>> tree.
>>
>>
>> Thank You, Christophe
>>
>>

Report message to a moderator

Re: Xtext CDO integration. [message #684305 is a reply to message #684279]

Wed, 15 June 2011 10:56

Eike Stepper

Messages: 6682
Registered: July 2009

Senior Member

Am 15.06.2011 12:34, schrieb Christophe Bouhier:
> Hi there,
>
> Just to let people know, we managed to get the CDO integration with xtext working without too much hassle. The following adaptations were needed:
>
>
> - Register CDOResourceServiceProvider with an extension like this:
>
> <extension point="org.eclipse.xtext.protocol_resourceServiceProvider">
> <resourceServiceProvider
> class="xxx.ExecutableExtensionFactory:xxx.CDOResourceServiceProvider"
> protocolName="cdo">
> </resourceServiceProvider>
> </extension>
>
> The ServiceProvider, extends the DefaultResourceServiceProvider and overrides: canHandle(URI uri) to return through on scheme "cdo"
>
>
> - CDOGlobalScopeProvider
>
> What it does, is feed a list of CDO type URI's which look like this cdo://repo/"resource name"
>
> further on, to build the scope we need an IResourceDescriptions. Our version, gets the CDO URI, and connects to the CDO repo. The returned CDO resource is fed to the created CDOResourceServiceProvider.getResourceDescriptionManager.getResourceDescription(cdoResource).
>
> We also needed to customize the name provider which is used in the IDefaultResourceDescriptionStrategy, to make sure that our references appear. (that is not specific to CDO).
>
>
> Next: It would be nice to see, if reference indexes can be re-used in the IResourceDescriptions from the CDO server side. Not sure what the API for this is on CDO side...
You may want to play with these CDOView methods:

org.eclipse.emf.cdo.view.CDOView.queryXRefs(CDOObject, EReference...)
org.eclipse.emf.cdo.view.CDOView.queryXRefs(Set<CDOObject>, EReference...)
org.eclipse.emf.cdo.view.CDOView.queryXRefsAsync(Set<CDOObject>, EReference...)

I'm here to help if the JavaDoc is not clear enough ;-)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

>
> Cheers Christophe
>
>
> On 10-06-11 18:54, Eike Stepper wrote:
>> Hi Christophe,
>>
>> That sounds very interesting. Have you considered the challenge that,
>> AFAIK, the Xtext parser creates a *new* model with each pass rather than
>> updating an existing one? That may not be what you want if your models
>> are stored in a repository where *all* their elements have unique
>> technical identifiers that other objects use as references.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>>
>>
>> Am 10.06.2011 16:12, schrieb Christophe Bouhier:
>>> Dear XText community,
>>>
>>> We want to integrate xtext with a CDO Repository, for our expression
>>> DSL grammar. This is roughly the intend in two working scenarios, and
>>> I would like to ask, if the approach is correct, and we have no
>>> oversight, on which xtext services, customization is necessary.
>>>
>>> A) Editing the DSL.
>>> -------------------
>>>
>>> 1) A global scope provider, with capabilities to resolve IScope for
>>> CDO based resources allows us to create references in our expression
>>> DSL to external model objects which reside in the CDO repository.
>>>
>>> For this: I foresee, customizing the following services:
>>>
>>> IGlobalScopeProvider
>>> (Likely an adaptation of DefaultGlobalScopeProvider)
>>>
>>> IQualifiedNameProvider
>>> (Likely an adaptation of SimpleNameProvider).
>>>
>>> IResourceServiceProvider
>>> (An implementation which can deal with CDO URI).
>>>
>>> IResourceDescriptions
>>> (Perhaps not needed, if we can load our CDO resource in the
>>> resourceset, we can use: ResourceSetBasedResourceDescriptions).
>>>
>>>
>>> On the linking side, we foresee that the workspace builder would need
>>> to be replaced / adapted aswell to load resources from the CDO Repo.
>>> Perhaps we need to adapt the LazyLinker to deal with CDO proxies and
>>> EPackage resolving:
>>>
>>>
>>> IXtextBuilderParticipant, This I am not sure about. Do we need a
>>> workspace builder at all when dealing with a CDO Repository? Our xtext
>>> editor will be running in an RCP app. (Which has a workspace if needed).
>>>
>>> B) Executing the DSL server side.
>>> ---------------------------------
>>>
>>> 1) Our DSL instance is stored as a String in our Domain (Non-Xtext
>>> model).
>>> 2) The grammar is de-serialized when needed, the Linker should kick-in
>>> to link the references (Lazily?), if all are resolved. (CDO URI's will
>>> be resolved).
>>> 3) The expression interpreter is called, with the valid grammar parse
>>> tree.
>>>
>>>
>>> Thank You, Christophe
>>>
>>>
>

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper

Report message to a moderator

Previous Topic:	[Xtend2] Where is ONFILECLOSE in Xtend2?
Next Topic:	Syntax Coloring -- cannot set color to Black

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Apr 24 14:33:16 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter