Home » Modeling » EMF » [xcore] Xcore at EclipseCon Europe
| [xcore] Xcore at EclipseCon Europe [message #757957] |
Thu, 17 November 2011 12:14  |
 Hallvard Traetteberg
Messages: 673
Registered: July 2009
Location: Trondheim, Norway |
Senior Member |
|
|
Hi,
Ed pointed me to the video from EclipseCon Europe, for those of us who
wouldn't attend:
http://www.fosslc.org/drupal/content/xcore-ecore-meets-xtext
It was informative (even without the presenters' proud faces as it was
slides and sound only).
I have a couple of comments/questions (after having used Xcore for a
while and seeing the presentation):
- I think xcore may vitalize the ecore field by making it easier to use
for 'ordinary' programmers, which I think is great!
- It seems Xcore is meant to be used as a replacement for ecore in many
scenarios, e.g. you model with xcore and create dynamic instances.
However, xcore files cannot be used as a drop-in replacement for ecore
files, since the inferred ecore model in the resource is not the first
element (same goes for the genmodel). Tools that process ecore/genmodel
files will need to be aware that epackages/genpackages may be anywhere
in the resource content list.
- The inferred objects are ecore, genmodel and jvmtype objects. The
first two kinds have a single root object, while the jvmtype objects
fill the rest of the content. I suggest creating a container for the
jvmtype objects, both to avoid clutter and to make it easier to support
other inferred objects (in containers) at fixed positions in the list.
- The technique of inferring other models from the parsed one, and
providing the inferred models to other tools (transformations, code
generators etc.) is very powerful. Currently, the inferred models are
appended to the resource's content list, after the parsed model. The
tools that process the inferred models will may start depending on the
(fixed) position, which will break them if used in a different context.
E.g. a different DSL may want to infer an xcore model that in turn
infers the ecore and genmodels. This will be difficult if the existing
tools make assumptions about the positions. I think we'll need to
discuss alternative and more flexible designs. One possibility is always
looking up models in the resource content list by type, rather than
position, another is adding (a very simple) API for accessing the
resource content list, e.g. Resource.get(type) where type is handled
like Adapter.isAdapterForType (rules defined by implementation, but
often the Java type, could be the eclass).
- I have used xcore directly with an xtext-based DSL that refers to
genpackages. The xcore file seemed to be indexed correctly, but there
was problems resolving references into it, where the URIs where of the
form model.xcore#<part1>-=-<part2>. Hence, I needed to switch to using
ecore instead.
Hallvard
|
|
|
| Re: [xcore] Xcore at EclipseCon Europe [message #757959 is a reply to message #757957] |
Thu, 17 November 2011 12:31  |
Ed Merks
Messages: 33140
Registered: July 2009 |
Senior Member |
|
|
Hallvard,
Comments below.
On 17/11/2011 1:14 PM, Hallvard Trætteberg wrote:
> Hi,
>
> Ed pointed me to the video from EclipseCon Europe, for those of us who
> wouldn't attend:
> http://www.fosslc.org/drupal/content/xcore-ecore-meets-xtext
>
> It was informative (even without the presenters' proud faces as it was
> slides and sound only).
>
> I have a couple of comments/questions (after having used Xcore for a
> while and seeing the presentation):
>
> - I think xcore may vitalize the ecore field by making it easier to
> use for 'ordinary' programmers, which I think is great!
Yes, people won't feel as if they're modeling but simple programming...
>
> - It seems Xcore is meant to be used as a replacement for ecore in
> many scenarios, e.g. you model with xcore and create dynamic
> instances. However, xcore files cannot be used as a drop-in
> replacement for ecore files, since the inferred ecore model in the
> resource is not the first element (same goes for the genmodel).
Yes, that's true. We'll certainly need to improve the references to be
more symbolic rather than /1 and /2...
> Tools that process ecore/genmodel files will need to be aware that
> epackages/genpackages may be anywhere in the resource content list.
Yes, and to be willing to open *.xcore resources.
>
> - The inferred objects are ecore, genmodel and jvmtype objects. The
> first two kinds have a single root object, while the jvmtype objects
> fill the rest of the content.
Yes, kind of messy...
> I suggest creating a container for the jvmtype objects, both to avoid
> clutter and to make it easier to support other inferred objects (in
> containers) at fixed positions in the list.
That sounds like a good idea...
>
> - The technique of inferring other models from the parsed one, and
> providing the inferred models to other tools (transformations, code
> generators etc.) is very powerful. Currently, the inferred models are
> appended to the resource's content list, after the parsed model. The
> tools that process the inferred models will may start depending on the
> (fixed) position, which will break them if used in a different context.
Yes, it needs to be symbolic in some way. I started working on that
(and to handle mutually dependent models), but ran out of time before
conference and demo camp season...
> E.g. a different DSL may want to infer an xcore model that in turn
> infers the ecore and genmodels.
I mentioned that to Sven...
> This will be difficult if the existing tools make assumptions about
> the positions. I think we'll need to discuss alternative and more
> flexible designs. One possibility is always looking up models in the
> resource content list by type, rather than position, another is adding
> (a very simple) API for accessing the resource content list, e.g.
> Resource.get(type) where type is handled like Adapter.isAdapterForType
> (rules defined by implementation, but often the Java type, could be
> the eclass).
There are already utility methods like this in EcoreUtil, e.g.,
getObjectByType...
>
> - I have used xcore directly with an xtext-based DSL that refers to
> genpackages. The xcore file seemed to be indexed correctly, but there
> was problems resolving references into it, where the URIs where of the
> form model.xcore#<part1>-=-<part2>. Hence, I needed to switch to using
> ecore instead.
There are still some linking issues I need to resolve properly. I.e.,
the builder used for indexing is kind of a hack and needs to be replaced
with something that indexes the unlinked inferred model.
>
> Hallvard
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:09:41 GMT 2024
Powered by FUDForum. Page generated in 0.02681 seconds |
] 
Search
Help
Register
Login
Home
