Eclipse Community Forums: TMF (Xtext) » library approach and global scoping

Help

Home

Home » Modeling » TMF (Xtext) » library approach and global scoping

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

library approach and global scoping [message #1032337]

Tue, 02 April 2013 22:14

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

Hi

in an example DSL (not based on Xbase) I have a sort of entity program
which can refer to other entities stored in another program. I'll try
to simplify the context as much as possible.

In particular, I also provide some library files with some library
entities (library files are available in a separate bundle).

For instance these are two library files

Object.mydsl

entity Object {
String toString() {...}
}

String.mydsl

entity String extends Object {
}

if in a plugin project I set a dependency on the library bundle, Object
and String can be correctly referred and resolved.

However, since the two library files are mutually dependent, the cross
references in the library files themselves are not correctly resolved
(e.g., the "String" reference in the method "toString()" at runtime is
still a proxy, and I can't seem to force its resolution in anyway).

How could I deal with that? Should I implement a custom
LazyLinkingResource, load all library files (without crossreference
resolution) and then force the resolution?

any hint please?

thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it

HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition

Report message to a moderator

Re: library approach and global scoping [message #1033680 is a reply to message #1032337]

Thu, 04 April 2013 14:08

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
> Hi
>
> in an example DSL (not based on Xbase) I have a sort of entity program
> which can refer to other entities stored in another program. I'll try
> to simplify the context as much as possible.
>
> In particular, I also provide some library files with some library
> entities (library files are available in a separate bundle).
>
> For instance these are two library files
>
> Object.mydsl
>
> entity Object {
> String toString() {...}
> }
>
> String.mydsl
>
> entity String extends Object {
> }
>
> if in a plugin project I set a dependency on the library bundle, Object
> and String can be correctly referred and resolved.
>
> However, since the two library files are mutually dependent, the cross
> references in the library files themselves are not correctly resolved
> (e.g., the "String" reference in the method "toString()" at runtime is
> still a proxy, and I can't seem to force its resolution in anyway).
>
> How could I deal with that? Should I implement a custom
> LazyLinkingResource, load all library files (without crossreference
> resolution) and then force the resolution?
>

any clue please?

thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it

Report message to a moderator

Re: library approach and global scoping [message #1034378 is a reply to message #1033680]

Fri, 05 April 2013 11:13

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

I can't figure out how to answer, the question is not concrete enought
to provide a simple answer - instead it gets very big, i.e. trying to
answer how containers, visibility and linking works.

Can you describe this in more concrete terms from the point of view what
is not working?

- henrik

On 2013-04-04 16:08, Lorenzo Bettini wrote:
> On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
>> Hi
>>
>> in an example DSL (not based on Xbase) I have a sort of entity program
>> which can refer to other entities stored in another program. I'll try
>> to simplify the context as much as possible.
>>
>> In particular, I also provide some library files with some library
>> entities (library files are available in a separate bundle).
>>
>> For instance these are two library files
>>
>> Object.mydsl
>>
>> entity Object {
>> String toString() {...}
>> }
>>
>> String.mydsl
>>
>> entity String extends Object {
>> }
>>
>> if in a plugin project I set a dependency on the library bundle, Object
>> and String can be correctly referred and resolved.
>>
>> However, since the two library files are mutually dependent, the cross
>> references in the library files themselves are not correctly resolved
>> (e.g., the "String" reference in the method "toString()" at runtime is
>> still a proxy, and I can't seem to force its resolution in anyway).
>>
>> How could I deal with that? Should I implement a custom
>> LazyLinkingResource, load all library files (without crossreference
>> resolution) and then force the resolution?
>>
>
> any clue please?
>
> thanks in advance
> Lorenzo
>
>

Report message to a moderator

Re: library approach and global scoping [message #1034388 is a reply to message #1034378]

Fri, 05 April 2013 11:26

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

I'm trying to setup a simple example (with Greetings DSL) to show the
problem...

basically if your DSL (not based on Xbase) ships some library files
(e.g., with .mydsl extension) in a plugin project, the elements of the
library files can be correctly referenced in another project (which
depends on the library project), but the elements of the library files
themselves look like they are not linked together (i.e., if an element
of a library file refers to an element of another library file, in the
same library project of course, the cross-reference is not resolved...).

hope to come up with an example soon

cheers
Lorenzo

On 04/05/2013 01:13 PM, Henrik Lindberg wrote:
> I can't figure out how to answer, the question is not concrete enought
> to provide a simple answer - instead it gets very big, i.e. trying to
> answer how containers, visibility and linking works.
>
> Can you describe this in more concrete terms from the point of view what
> is not working?
>
> - henrik
>
> On 2013-04-04 16:08, Lorenzo Bettini wrote:
>> On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
>>> Hi
>>>
>>> in an example DSL (not based on Xbase) I have a sort of entity program
>>> which can refer to other entities stored in another program. I'll try
>>> to simplify the context as much as possible.
>>>
>>> In particular, I also provide some library files with some library
>>> entities (library files are available in a separate bundle).
>>>
>>> For instance these are two library files
>>>
>>> Object.mydsl
>>>
>>> entity Object {
>>> String toString() {...}
>>> }
>>>
>>> String.mydsl
>>>
>>> entity String extends Object {
>>> }
>>>
>>> if in a plugin project I set a dependency on the library bundle, Object
>>> and String can be correctly referred and resolved.
>>>
>>> However, since the two library files are mutually dependent, the cross
>>> references in the library files themselves are not correctly resolved
>>> (e.g., the "String" reference in the method "toString()" at runtime is
>>> still a proxy, and I can't seem to force its resolution in anyway).
>>>
>>> How could I deal with that? Should I implement a custom
>>> LazyLinkingResource, load all library files (without crossreference
>>> resolution) and then force the resolution?
>>>
>>
>> any clue please?
>>
>> thanks in advance
>> Lorenzo
>>
>>
>

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it

Report message to a moderator

Re: library approach and global scoping [message #1034503 is a reply to message #1034388]

Fri, 05 April 2013 14:02

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

I assume you are relying on the Xtext Java/OSGi classpath support to
link bundles together?
Maybe it is a bundle start issue - try tweaking your launch config to
ensure the "library bundle" is started. Does that make a difference?

Does a "build clean" change anything?

Regards
- henrik

On 2013-05-04 13:26, Lorenzo Bettini wrote:
> I'm trying to setup a simple example (with Greetings DSL) to show the
> problem...
>
> basically if your DSL (not based on Xbase) ships some library files
> (e.g., with .mydsl extension) in a plugin project, the elements of the
> library files can be correctly referenced in another project (which
> depends on the library project), but the elements of the library files
> themselves look like they are not linked together (i.e., if an element
> of a library file refers to an element of another library file, in the
> same library project of course, the cross-reference is not resolved...).
>
> hope to come up with an example soon
>
> cheers
> Lorenzo
>
> On 04/05/2013 01:13 PM, Henrik Lindberg wrote:
>> I can't figure out how to answer, the question is not concrete enought
>> to provide a simple answer - instead it gets very big, i.e. trying to
>> answer how containers, visibility and linking works.
>>
>> Can you describe this in more concrete terms from the point of view what
>> is not working?
>>
>> - henrik
>>
>> On 2013-04-04 16:08, Lorenzo Bettini wrote:
>>> On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
>>>> Hi
>>>>
>>>> in an example DSL (not based on Xbase) I have a sort of entity program
>>>> which can refer to other entities stored in another program. I'll try
>>>> to simplify the context as much as possible.
>>>>
>>>> In particular, I also provide some library files with some library
>>>> entities (library files are available in a separate bundle).
>>>>
>>>> For instance these are two library files
>>>>
>>>> Object.mydsl
>>>>
>>>> entity Object {
>>>> String toString() {...}
>>>> }
>>>>
>>>> String.mydsl
>>>>
>>>> entity String extends Object {
>>>> }
>>>>
>>>> if in a plugin project I set a dependency on the library bundle, Object
>>>> and String can be correctly referred and resolved.
>>>>
>>>> However, since the two library files are mutually dependent, the cross
>>>> references in the library files themselves are not correctly resolved
>>>> (e.g., the "String" reference in the method "toString()" at runtime is
>>>> still a proxy, and I can't seem to force its resolution in anyway).
>>>>
>>>> How could I deal with that? Should I implement a custom
>>>> LazyLinkingResource, load all library files (without crossreference
>>>> resolution) and then force the resolution?
>>>>
>>>
>>> any clue please?
>>>
>>> thanks in advance
>>> Lorenzo
>>>
>>>
>>
>
>

Report message to a moderator

Re: library approach and global scoping [message #1034540 is a reply to message #1034503]

Fri, 05 April 2013 15:05

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 04/05/2013 04:02 PM, Henrik Lindberg wrote:
> I assume you are relying on the Xtext Java/OSGi classpath support to
> link bundles together?
> Maybe it is a bundle start issue - try tweaking your launch config to
> ensure the "library bundle" is started. Does that make a difference?

actually the library files are part of the runtime plug-in project for
the DSL, say org.xtext.example.mydsl, and that is part of the launch
configuration; in the launch configuration all workspace plugins are
enabled.

In the new eclipse instance, I create an example plug-in project with
Xtext nature, and add the org.xtext.example.mydsl as dependency.

Please let me stress that in the example plug-in project I can correctly
refer to elements in the library files (which are part of Plug-in
Dependencies). However, in the EMF models corresponding to the library
files, cross-references across files are not resolved.

Let me (try to) be more precise: consider these two library files (I'll
try to simplify the context, of course "extends" is a cross reference to
Entity)

FILE: lib1.mydsl

entity Object {}

entity String extends Object {}

FILE: lib2.mydsl

entity List extends Object {}

in the new eclipse instance, where these two files are in Plug-in
Dependencies, String correctly refers to Object (they are in the same
file); while List cannot refer to Object (with the debugger I can see
that the reference is still a proxy, and the corresponding URI is not
resolved).

The funny thing is that in a headless environment everything works,
since I first load all the resources (including the ones corresponding
to libraries) and then perform the validation after all resources are
loaded.

In the Eclipse context it looks like the models which correspond to
mydsl files in the Plug-in Dependencies do not support cross-references
across files...

>
> Does a "build clean" change anything?
>

No, nothing changes, since the LazyLinkingResources corresponding to
files in Plug-in Dependencies do not seem to be reloaded anyway...

cheers
Lorenzo

> Regards
> - henrik
>
> On 2013-05-04 13:26, Lorenzo Bettini wrote:
>> I'm trying to setup a simple example (with Greetings DSL) to show the
>> problem...
>>
>> basically if your DSL (not based on Xbase) ships some library files
>> (e.g., with .mydsl extension) in a plugin project, the elements of the
>> library files can be correctly referenced in another project (which
>> depends on the library project), but the elements of the library files
>> themselves look like they are not linked together (i.e., if an element
>> of a library file refers to an element of another library file, in the
>> same library project of course, the cross-reference is not resolved...).
>>
>> hope to come up with an example soon
>>
>> cheers
>> Lorenzo
>>
>> On 04/05/2013 01:13 PM, Henrik Lindberg wrote:
>>> I can't figure out how to answer, the question is not concrete enought
>>> to provide a simple answer - instead it gets very big, i.e. trying to
>>> answer how containers, visibility and linking works.
>>>
>>> Can you describe this in more concrete terms from the point of view what
>>> is not working?
>>>
>>> - henrik
>>>
>>> On 2013-04-04 16:08, Lorenzo Bettini wrote:
>>>> On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
>>>>> Hi
>>>>>
>>>>> in an example DSL (not based on Xbase) I have a sort of entity program
>>>>> which can refer to other entities stored in another program. I'll try
>>>>> to simplify the context as much as possible.
>>>>>
>>>>> In particular, I also provide some library files with some library
>>>>> entities (library files are available in a separate bundle).
>>>>>
>>>>> For instance these are two library files
>>>>>
>>>>> Object.mydsl
>>>>>
>>>>> entity Object {
>>>>> String toString() {...}
>>>>> }
>>>>>
>>>>> String.mydsl
>>>>>
>>>>> entity String extends Object {
>>>>> }
>>>>>
>>>>> if in a plugin project I set a dependency on the library bundle,
>>>>> Object
>>>>> and String can be correctly referred and resolved.
>>>>>
>>>>> However, since the two library files are mutually dependent, the cross
>>>>> references in the library files themselves are not correctly resolved
>>>>> (e.g., the "String" reference in the method "toString()" at runtime is
>>>>> still a proxy, and I can't seem to force its resolution in anyway).
>>>>>
>>>>> How could I deal with that? Should I implement a custom
>>>>> LazyLinkingResource, load all library files (without crossreference
>>>>> resolution) and then force the resolution?
>>>>>
>>>>
>>>> any clue please?
>>>>
>>>> thanks in advance
>>>> Lorenzo
>>>>
>>>>
>>>
>>
>>
>

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it

Report message to a moderator

Re: library approach and global scoping [message #1034652 is a reply to message #1034540]

Fri, 05 April 2013 18:17

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

It works headless because you add all resources to the resource set
before linking (everything is there, no need for proxies).

It seems to work when you are in the IDE as well because you get a
proxy. That means it managed to link to something (or you would not have
a proxy IIRC). What does the proxy contain is it a valid reference? Do
you get an error if you try to resolve it?

URI uri = EcoreUtil.getURI(d.getEObjectOrProxy());
What is the URI?

This is supposed to work:

EObject x = ref.getEObjectOrProxy();
if(x.eIsProxy())
x = EcoreUtil.resolve(x, o); // o is the reference object

If that does not work, try to debug through this sequence and see where
it gives up.

Does that help, or did you already try these things. If so, then it
sounds like a bug.

- henrik

On 2013-05-04 17:05, Lorenzo Bettini wrote:
> On 04/05/2013 04:02 PM, Henrik Lindberg wrote:
>> I assume you are relying on the Xtext Java/OSGi classpath support to
>> link bundles together?
>> Maybe it is a bundle start issue - try tweaking your launch config to
>> ensure the "library bundle" is started. Does that make a difference?
>
> actually the library files are part of the runtime plug-in project for
> the DSL, say org.xtext.example.mydsl, and that is part of the launch
> configuration; in the launch configuration all workspace plugins are
> enabled.
>
> In the new eclipse instance, I create an example plug-in project with
> Xtext nature, and add the org.xtext.example.mydsl as dependency.
>
> Please let me stress that in the example plug-in project I can correctly
> refer to elements in the library files (which are part of Plug-in
> Dependencies). However, in the EMF models corresponding to the library
> files, cross-references across files are not resolved.
>
> Let me (try to) be more precise: consider these two library files (I'll
> try to simplify the context, of course "extends" is a cross reference to
> Entity)
>
> FILE: lib1.mydsl
>
> entity Object {}
>
> entity String extends Object {}
>
> FILE: lib2.mydsl
>
> entity List extends Object {}
>
> in the new eclipse instance, where these two files are in Plug-in
> Dependencies, String correctly refers to Object (they are in the same
> file); while List cannot refer to Object (with the debugger I can see
> that the reference is still a proxy, and the corresponding URI is not
> resolved).
>
> The funny thing is that in a headless environment everything works,
> since I first load all the resources (including the ones corresponding
> to libraries) and then perform the validation after all resources are
> loaded.
>
> In the Eclipse context it looks like the models which correspond to
> mydsl files in the Plug-in Dependencies do not support cross-references
> across files...
>
>>
>> Does a "build clean" change anything?
>>
>
> No, nothing changes, since the LazyLinkingResources corresponding to
> files in Plug-in Dependencies do not seem to be reloaded anyway...
>
> cheers
> Lorenzo
>
>> Regards
>> - henrik
>>
>> On 2013-05-04 13:26, Lorenzo Bettini wrote:
>>> I'm trying to setup a simple example (with Greetings DSL) to show the
>>> problem...
>>>
>>> basically if your DSL (not based on Xbase) ships some library files
>>> (e.g., with .mydsl extension) in a plugin project, the elements of the
>>> library files can be correctly referenced in another project (which
>>> depends on the library project), but the elements of the library files
>>> themselves look like they are not linked together (i.e., if an element
>>> of a library file refers to an element of another library file, in the
>>> same library project of course, the cross-reference is not resolved...).
>>>
>>> hope to come up with an example soon
>>>
>>> cheers
>>> Lorenzo
>>>
>>> On 04/05/2013 01:13 PM, Henrik Lindberg wrote:
>>>> I can't figure out how to answer, the question is not concrete enought
>>>> to provide a simple answer - instead it gets very big, i.e. trying to
>>>> answer how containers, visibility and linking works.
>>>>
>>>> Can you describe this in more concrete terms from the point of view what
>>>> is not working?
>>>>
>>>> - henrik
>>>>
>>>> On 2013-04-04 16:08, Lorenzo Bettini wrote:
>>>>> On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
>>>>>> Hi
>>>>>>
>>>>>> in an example DSL (not based on Xbase) I have a sort of entity program
>>>>>> which can refer to other entities stored in another program. I'll try
>>>>>> to simplify the context as much as possible.
>>>>>>
>>>>>> In particular, I also provide some library files with some library
>>>>>> entities (library files are available in a separate bundle).
>>>>>>
>>>>>> For instance these are two library files
>>>>>>
>>>>>> Object.mydsl
>>>>>>
>>>>>> entity Object {
>>>>>> String toString() {...}
>>>>>> }
>>>>>>
>>>>>> String.mydsl
>>>>>>
>>>>>> entity String extends Object {
>>>>>> }
>>>>>>
>>>>>> if in a plugin project I set a dependency on the library bundle,
>>>>>> Object
>>>>>> and String can be correctly referred and resolved.
>>>>>>
>>>>>> However, since the two library files are mutually dependent, the cross
>>>>>> references in the library files themselves are not correctly resolved
>>>>>> (e.g., the "String" reference in the method "toString()" at runtime is
>>>>>> still a proxy, and I can't seem to force its resolution in anyway).
>>>>>>
>>>>>> How could I deal with that? Should I implement a custom
>>>>>> LazyLinkingResource, load all library files (without crossreference
>>>>>> resolution) and then force the resolution?
>>>>>>
>>>>>
>>>>> any clue please?
>>>>>
>>>>> thanks in advance
>>>>> Lorenzo
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Report message to a moderator

Re: library approach and global scoping [message #1035032 is a reply to message #1034652]

Sat, 06 April 2013 07:50

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

On 04/05/2013 08:17 PM, Henrik Lindberg wrote:
> It works headless because you add all resources to the resource set
> before linking (everything is there, no need for proxies).

yes indeed; it was clear to me, sorry if I made it sound like magic ;)

however, as far as I understand, proxies are actually installed when
resources are loaded and first lazy linked (i.e., when the contents of
file are parsed, proxies are installed for references: they are actually
then resolved when validation is run).

>
> It seems to work when you are in the IDE as well because you get a
> proxy. That means it managed to link to something (or you would not have

mh... as I said above, I think that proxies are set when the program is
parsed, aren't they?

> a proxy IIRC). What does the proxy contain is it a valid reference? Do
> you get an error if you try to resolve it?

it is a URI which ends with #xtext...

>
> URI uri = EcoreUtil.getURI(d.getEObjectOrProxy());
> What is the URI?
>
> This is supposed to work:
>
> EObject x = ref.getEObjectOrProxy();
> if(x.eIsProxy())
> x = EcoreUtil.resolve(x, o); // o is the reference object
>
> If that does not work, try to debug through this sequence and see where
> it gives up.
>
> Does that help, or did you already try these things. If so, then it
> sounds like a bug.

I had already tried most of these things, but I can't seem to solve
those references with URI which end with #xtext...

but again, this problem is for references which cross files, and when
the files are in a required bundle.

I'll try to reproduce the problem in a simpler language...

by the way, I'm using Xtext 2.4.

thanks
Lorenzo

>
> - henrik
>
> On 2013-05-04 17:05, Lorenzo Bettini wrote:
>> On 04/05/2013 04:02 PM, Henrik Lindberg wrote:
>>> I assume you are relying on the Xtext Java/OSGi classpath support to
>>> link bundles together?
>>> Maybe it is a bundle start issue - try tweaking your launch config to
>>> ensure the "library bundle" is started. Does that make a difference?
>>
>> actually the library files are part of the runtime plug-in project for
>> the DSL, say org.xtext.example.mydsl, and that is part of the launch
>> configuration; in the launch configuration all workspace plugins are
>> enabled.
>>
>> In the new eclipse instance, I create an example plug-in project with
>> Xtext nature, and add the org.xtext.example.mydsl as dependency.
>>
>> Please let me stress that in the example plug-in project I can correctly
>> refer to elements in the library files (which are part of Plug-in
>> Dependencies). However, in the EMF models corresponding to the library
>> files, cross-references across files are not resolved.
>>
>> Let me (try to) be more precise: consider these two library files (I'll
>> try to simplify the context, of course "extends" is a cross reference to
>> Entity)
>>
>> FILE: lib1.mydsl
>>
>> entity Object {}
>>
>> entity String extends Object {}
>>
>> FILE: lib2.mydsl
>>
>> entity List extends Object {}
>>
>> in the new eclipse instance, where these two files are in Plug-in
>> Dependencies, String correctly refers to Object (they are in the same
>> file); while List cannot refer to Object (with the debugger I can see
>> that the reference is still a proxy, and the corresponding URI is not
>> resolved).
>>
>> The funny thing is that in a headless environment everything works,
>> since I first load all the resources (including the ones corresponding
>> to libraries) and then perform the validation after all resources are
>> loaded.
>>
>> In the Eclipse context it looks like the models which correspond to
>> mydsl files in the Plug-in Dependencies do not support cross-references
>> across files...
>>
>>>
>>> Does a "build clean" change anything?
>>>
>>
>> No, nothing changes, since the LazyLinkingResources corresponding to
>> files in Plug-in Dependencies do not seem to be reloaded anyway...
>>
>> cheers
>> Lorenzo
>>
>>> Regards
>>> - henrik
>>>
>>> On 2013-05-04 13:26, Lorenzo Bettini wrote:
>>>> I'm trying to setup a simple example (with Greetings DSL) to show the
>>>> problem...
>>>>
>>>> basically if your DSL (not based on Xbase) ships some library files
>>>> (e.g., with .mydsl extension) in a plugin project, the elements of the
>>>> library files can be correctly referenced in another project (which
>>>> depends on the library project), but the elements of the library files
>>>> themselves look like they are not linked together (i.e., if an element
>>>> of a library file refers to an element of another library file, in the
>>>> same library project of course, the cross-reference is not
>>>> resolved...).
>>>>
>>>> hope to come up with an example soon
>>>>
>>>> cheers
>>>> Lorenzo
>>>>
>>>> On 04/05/2013 01:13 PM, Henrik Lindberg wrote:
>>>>> I can't figure out how to answer, the question is not concrete enought
>>>>> to provide a simple answer - instead it gets very big, i.e. trying to
>>>>> answer how containers, visibility and linking works.
>>>>>
>>>>> Can you describe this in more concrete terms from the point of view
>>>>> what
>>>>> is not working?
>>>>>
>>>>> - henrik
>>>>>
>>>>> On 2013-04-04 16:08, Lorenzo Bettini wrote:
>>>>>> On 04/03/2013 12:14 AM, Lorenzo Bettini wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> in an example DSL (not based on Xbase) I have a sort of entity
>>>>>>> program
>>>>>>> which can refer to other entities stored in another program.
>>>>>>> I'll try
>>>>>>> to simplify the context as much as possible.
>>>>>>>
>>>>>>> In particular, I also provide some library files with some library
>>>>>>> entities (library files are available in a separate bundle).
>>>>>>>
>>>>>>> For instance these are two library files
>>>>>>>
>>>>>>> Object.mydsl
>>>>>>>
>>>>>>> entity Object {
>>>>>>> String toString() {...}
>>>>>>> }
>>>>>>>
>>>>>>> String.mydsl
>>>>>>>
>>>>>>> entity String extends Object {
>>>>>>> }
>>>>>>>
>>>>>>> if in a plugin project I set a dependency on the library bundle,
>>>>>>> Object
>>>>>>> and String can be correctly referred and resolved.
>>>>>>>
>>>>>>> However, since the two library files are mutually dependent, the
>>>>>>> cross
>>>>>>> references in the library files themselves are not correctly
>>>>>>> resolved
>>>>>>> (e.g., the "String" reference in the method "toString()" at
>>>>>>> runtime is
>>>>>>> still a proxy, and I can't seem to force its resolution in anyway).
>>>>>>>
>>>>>>> How could I deal with that? Should I implement a custom
>>>>>>> LazyLinkingResource, load all library files (without crossreference
>>>>>>> resolution) and then force the resolution?
>>>>>>>
>>>>>>
>>>>>> any clue please?
>>>>>>
>>>>>> thanks in advance
>>>>>> Lorenzo
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it

Report message to a moderator

Re: library approach and global scoping [message #1035307 is a reply to message #1035032]

Sat, 06 April 2013 17:29

Steve Kallestad

Messages: 62
Registered: March 2013

Member

I had a similar problem last night.

I had a line in place to resolve proxies:
but as it turned out, the proxy was not resolving. I checked this by adding a line just after the resolution logging whether or not the object was still a proxy.

EObject resolved = EcoreUtil.resolve(unresolvedEObject, *struggledToGetRightResource*);
logger.debug("Resolved: {}", resolved.eIsProxy());

In my particular case, since I put the wrong variable as the second parameter, the resolve function was simply returning me the same proxy. After toying around with things for a bit, I was able to obtain the correct resource.

Once I did that, the code relying on a resolved proxy worked as expected.

Report message to a moderator

Re: library approach and global scoping [message #1035383 is a reply to message #1035307]

Sat, 06 April 2013 20:11

Henrik Lindberg

Messages: 2509
Registered: July 2009

Senior Member

In case it helps, (and if IIRC), the reference object has to be an
EObject that is contained in a Resource that is in a ResourceSet.

- henrik

On 2013-06-04 19:29, Steve Kallestad wrote:
> I had a similar problem last night.
>
> I had a line in place to resolve proxies:
> but as it turned out, the proxy was not resolving. I checked this by
> adding a line just after the resolution logging whether or not the
> object was still a proxy.
>
>
> EObject resolved = EcoreUtil.resolve(unresolvedEObject,
> *struggledToGetRightResource*);
> logger.debug("Resolved: {}", resolved.eIsProxy());
>
>
> In my particular case, since I put the wrong variable as the second
> parameter, the resolve function was simply returning me the same proxy.
> After toying around with things for a bit, I was able to obtain the
> correct resource.
>
> Once I did that, the code relying on a resolved proxy worked as expected.

Report message to a moderator

Re: library approach and global scoping [message #1035682 is a reply to message #1035032]

Sun, 07 April 2013 08:07

Lorenzo Bettini

Messages: 1812
Registered: July 2009
Location: Firenze, Italy

Senior Member

Hi

here's a minimalistic example to reproduce the problem I was talking
about: https://github.com/LorenzoBettini/xtext-index-experiments

the grammar is really simple

Model:
greetings+=Greeting*;

Greeting:
HelloGreeting | RefGreeting ;

HelloGreeting:
'Hello' name=ID ('extends' parent=[HelloGreeting])? '!';

RefGreeting:
'ref' greeting=[HelloGreeting];

the main plug-in project, org.xtext.example.index.greetings, also
contains two .greetings files which can be seen as libraries (which are
exported in the MANIFEST)

StandardHello.greetings
-----------------------------------
Hello Default!
-----------------------------------

and
OtherStandardHello.greetings
-----------------------------------
Hello OtherDefault extends Default!
Hello OtherDefault2 extends OtherDefault!
-----------------------------------

note that the first greeting "OtherDefault" in the second file refers to
the greeting of the first file "Default", while the second greeting
refers to another greeting in the very same file.

Now, here's a label provider, which represents also the parent
greeting's name

class GreetingsLabelProvider extends
org.eclipse.xtext.ui.label.DefaultEObjectLabelProvider {

....
def text(RefGreeting ref) {
'ref: ' + ref.greeting.text
}

def String text(HelloGreeting hello) {
hello?.name +
if (hello.parent != null) {
" -> " + hello.parent.ensureIsResolved(hello).text
} else {
""
}
}

def ensureIsResolved(HelloGreeting ref, HelloGreeting context) {
if (ref.eIsProxy) {
val resolved = EcoreUtil::resolve(ref, context)
return resolved as HelloGreeting
}
return ref
}

note that it also checks whether the referred greeting is a proxy and in
case it tries to resolve it, passing as the context the main greeting
object (which is contained in a resource and a resource set).

This DSL comes with a project wizard, which creates a new plug-in
project, with Xtext nature, and which depends on
org.xtext.example.index.greetings, so that it can access the greetings
in the two library files.

Now, the example.greetings in this new project

Hello Xtext extends Default!
Hello Xtext2 extends OtherDefault!
ref Default
ref OtherDefault
ref OtherDefault2

can access greetings in the libraries; however, the greetings in the
library files are not completely resolved: let me show the library files
again

StandardHello.greetings
-----------------------------------
Hello Default!
-----------------------------------

OtherStandardHello.greetings
-----------------------------------
Hello OtherDefault extends Default!
Hello OtherDefault2 extends OtherDefault!
-----------------------------------

Now, "OtherDefault extends Default", and "Default" is not resolved (it
is defined in the other library file): it is a proxy

platform:/resource/.org.eclipse.jdt.core.external.folders/.link2/org/xtext/example/index/greetings/lib/OtherStandandHello.greetings#xtextLink_::0.0.0::1::/8

and it is marked as unresolved proxy in LazyLinkingResource.

You can try yourself, or take a look at the outline view in this screenshot

http://imageshack.us/a/img145/1928/helloindexide.png

"null" basically means that the reference is a proxy and there's no way
to resolve it.

After a long session of debugging, I think that what happens is that
when a dsl file is loaded from a dependency project (a plug-in
dependency), the global scope provider, when it accesses the Index, it
does not see its own container project as a visible container, thus, in
this case, OtherStandardHello.greetings does not see
StandardHello.greetings and thus, "Default" remains unresolved.

I hope the context and the symptoms are clear now

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it

Report message to a moderator

Previous Topic:	Question to help straightening some things out
Next Topic:	Using Xtext 2.3.1 Included Parser

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 12:17:48 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter