Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Epsilon » Possible bug in ETL/Emfatic?
Possible bug in ETL/Emfatic? [message #524031] Tue, 30 March 2010 12:12 Go to next message
Eclipse User
Originally posted by: c.k.holmes.lboro.ac.uk

Hi,
This may not be a bug at all and, rather, a lack of understanding on my
part; however ...

If we have a directory structure of the following form:
MyProject
Parent (directory)
parent.ecore
parent.emf
Child (directory)
child.ecore
child.emf

Each Emfatic file defines a namespace commensurate with its location in
the directory hierarchy:
parent
parent.child

And each defines its own package and imports the namespace directly
above it:
parent (doesn't import anything)
child (imports parent)

If package Parent defines a class Thing and package Child extends this
class as (say) AnotherThing then I can run a transformation
(MyTransformation) using Ant to provide a reference to package Child and
access the types Thing and AnotherThing via (e.g.)
Target!Thing
and
Target!AnotherThing

However, if package Child is empty or does not extend any of the classes
provided in package Parent, say Child now introduces the class Strange,
then using the same approach as above I find that:
Target!Strange is resolved correctly, but
Target!Thing can no longer be found.

Is this behaviour to be expected?

Regards
Chris
Re: Possible bug in ETL/Emfatic? [message #524034 is a reply to message #524031] Tue, 30 March 2010 12:21 Go to previous messageGo to next message
Dimitrios Kolovos is currently offline Dimitrios Kolovos
Messages: 1776
Registered: July 2009
Senior Member
Hi Chris,

This is the expected behaviour. The Emfatic "import" statement is just a
convenience mechanism so that you don't have to refer to external
EClasses using fully-qualified names (i.e. including namespace URI). If
you don't use (reference, extend) any EClasses from the imported
(parent) metamodel, then when you do the Emfatic->Ecore transformation
on the child metamodel, the "import" is not mapped to anything.

A solution for this would be to allow Epsilon to load a model using a
number of (instead of just one) unrelated metamodel URIs. This is
something we've been pondering as a feature for some time now but didn't
have a case study for. As a workaround you can use a third metamodel
which imports and somehow references classes from both the parent and
the child metamodels (even in abstract non-instantiable classes) and use
this to load your models.

Cheers,
Dimitris

Chris Holmes wrote:
> Hi,
> This may not be a bug at all and, rather, a lack of understanding on my
> part; however ...
>
> If we have a directory structure of the following form:
> MyProject
> Parent (directory)
> parent.ecore
> parent.emf
> Child (directory)
> child.ecore
> child.emf
>
> Each Emfatic file defines a namespace commensurate with its location in
> the directory hierarchy:
> parent
> parent.child
>
> And each defines its own package and imports the namespace directly
> above it:
> parent (doesn't import anything)
> child (imports parent)
>
> If package Parent defines a class Thing and package Child extends this
> class as (say) AnotherThing then I can run a transformation
> (MyTransformation) using Ant to provide a reference to package Child and
> access the types Thing and AnotherThing via (e.g.)
> Target!Thing
> and
> Target!AnotherThing
>
> However, if package Child is empty or does not extend any of the classes
> provided in package Parent, say Child now introduces the class Strange,
> then using the same approach as above I find that:
> Target!Strange is resolved correctly, but
> Target!Thing can no longer be found.
>
> Is this behaviour to be expected?
>
> Regards
> Chris


--
Spread the word: http://www.eclipse.org/gmt/epsilon/spreadtheword
Follow Epsilon on Twitter: http://twitter.com/epsilonews
Re: Possible bug in ETL/Emfatic? [message #524043 is a reply to message #524034] Tue, 30 March 2010 08:06 Go to previous messageGo to next message
Eclipse User
Originally posted by: c.k.holmes.lboro.ac.uk

Hi Dimitris,
OK, thanks for clarifying for me.

It occurred to me that I could have made Child a child package of Parent
such that Child should be able to the Parent's parts (I could do this
with XMF), however I don't know the syntax for either Emfatic or eCore
(I spent a while searching the web, but didn't find anything useful). Do
you know if this is possible, and, if so, could you provide an example
of the syntax?

Best Wishes
Chris

Dimitris Kolovos wrote:
> Hi Chris,
>
> This is the expected behaviour. The Emfatic "import" statement is just a
> convenience mechanism so that you don't have to refer to external
> EClasses using fully-qualified names (i.e. including namespace URI). If
> you don't use (reference, extend) any EClasses from the imported
> (parent) metamodel, then when you do the Emfatic->Ecore transformation
> on the child metamodel, the "import" is not mapped to anything.
>
> A solution for this would be to allow Epsilon to load a model using a
> number of (instead of just one) unrelated metamodel URIs. This is
> something we've been pondering as a feature for some time now but didn't
> have a case study for. As a workaround you can use a third metamodel
> which imports and somehow references classes from both the parent and
> the child metamodels (even in abstract non-instantiable classes) and use
> this to load your models.
>
> Cheers,
> Dimitris
>
> Chris Holmes wrote:
>> Hi,
>> This may not be a bug at all and, rather, a lack of understanding on
>> my part; however ...
>>
>> If we have a directory structure of the following form:
>> MyProject
>> Parent (directory)
>> parent.ecore
>> parent.emf
>> Child (directory)
>> child.ecore
>> child.emf
>>
>> Each Emfatic file defines a namespace commensurate with its location
>> in the directory hierarchy:
>> parent
>> parent.child
>>
>> And each defines its own package and imports the namespace directly
>> above it:
>> parent (doesn't import anything)
>> child (imports parent)
>>
>> If package Parent defines a class Thing and package Child extends this
>> class as (say) AnotherThing then I can run a transformation
>> (MyTransformation) using Ant to provide a reference to package Child
>> and access the types Thing and AnotherThing via (e.g.)
>> Target!Thing
>> and
>> Target!AnotherThing
>>
>> However, if package Child is empty or does not extend any of the
>> classes provided in package Parent, say Child now introduces the class
>> Strange, then using the same approach as above I find that:
>> Target!Strange is resolved correctly, but
>> Target!Thing can no longer be found.
>>
>> Is this behaviour to be expected?
>>
>> Regards
>> Chris
>
>
Re: Possible bug in ETL/Emfatic? [message #524044 is a reply to message #524043] Tue, 30 March 2010 08:06 Go to previous messageGo to next message
Dimitrios Kolovos is currently offline Dimitrios Kolovos
Messages: 1776
Registered: July 2009
Senior Member
Hi Chris,

Section 1.2 of http://www.eclipse.org/gmt/epsilon/doc/articles/emfatic/
provides examples for defining sub-packages in Emfatic. (this is a
relatively new article so Google may not have picked it up yet)

Cheers,
Dimitris

Chris Holmes wrote:
> Hi Dimitris,
> OK, thanks for clarifying for me.
>
> It occurred to me that I could have made Child a child package of Parent
> such that Child should be able to the Parent's parts (I could do this
> with XMF), however I don't know the syntax for either Emfatic or eCore
> (I spent a while searching the web, but didn't find anything useful). Do
> you know if this is possible, and, if so, could you provide an example
> of the syntax?
>
> Best Wishes
> Chris
>
> Dimitris Kolovos wrote:
>> Hi Chris,
>>
>> This is the expected behaviour. The Emfatic "import" statement is just
>> a convenience mechanism so that you don't have to refer to external
>> EClasses using fully-qualified names (i.e. including namespace URI).
>> If you don't use (reference, extend) any EClasses from the imported
>> (parent) metamodel, then when you do the Emfatic->Ecore transformation
>> on the child metamodel, the "import" is not mapped to anything.
>>
>> A solution for this would be to allow Epsilon to load a model using a
>> number of (instead of just one) unrelated metamodel URIs. This is
>> something we've been pondering as a feature for some time now but
>> didn't have a case study for. As a workaround you can use a third
>> metamodel which imports and somehow references classes from both the
>> parent and the child metamodels (even in abstract non-instantiable
>> classes) and use this to load your models.
>>
>> Cheers,
>> Dimitris
>>
>> Chris Holmes wrote:
>>> Hi,
>>> This may not be a bug at all and, rather, a lack of understanding on
>>> my part; however ...
>>>
>>> If we have a directory structure of the following form:
>>> MyProject
>>> Parent (directory)
>>> parent.ecore
>>> parent.emf
>>> Child (directory)
>>> child.ecore
>>> child.emf
>>>
>>> Each Emfatic file defines a namespace commensurate with its location
>>> in the directory hierarchy:
>>> parent
>>> parent.child
>>>
>>> And each defines its own package and imports the namespace directly
>>> above it:
>>> parent (doesn't import anything)
>>> child (imports parent)
>>>
>>> If package Parent defines a class Thing and package Child extends
>>> this class as (say) AnotherThing then I can run a transformation
>>> (MyTransformation) using Ant to provide a reference to package Child
>>> and access the types Thing and AnotherThing via (e.g.)
>>> Target!Thing
>>> and
>>> Target!AnotherThing
>>>
>>> However, if package Child is empty or does not extend any of the
>>> classes provided in package Parent, say Child now introduces the
>>> class Strange, then using the same approach as above I find that:
>>> Target!Strange is resolved correctly, but
>>> Target!Thing can no longer be found.
>>>
>>> Is this behaviour to be expected?
>>>
>>> Regards
>>> Chris
>>
>>


--
Spread the word: http://www.eclipse.org/gmt/epsilon/spreadtheword
Follow Epsilon on Twitter: http://twitter.com/epsilonews
Re: Possible bug in ETL/Emfatic? [message #588006 is a reply to message #524031] Tue, 30 March 2010 12:21 Go to previous messageGo to next message
Dimitrios Kolovos is currently offline Dimitrios Kolovos
Messages: 1776
Registered: July 2009
Senior Member
Hi Chris,

This is the expected behaviour. The Emfatic "import" statement is just a
convenience mechanism so that you don't have to refer to external
EClasses using fully-qualified names (i.e. including namespace URI). If
you don't use (reference, extend) any EClasses from the imported
(parent) metamodel, then when you do the Emfatic->Ecore transformation
on the child metamodel, the "import" is not mapped to anything.

A solution for this would be to allow Epsilon to load a model using a
number of (instead of just one) unrelated metamodel URIs. This is
something we've been pondering as a feature for some time now but didn't
have a case study for. As a workaround you can use a third metamodel
which imports and somehow references classes from both the parent and
the child metamodels (even in abstract non-instantiable classes) and use
this to load your models.

Cheers,
Dimitris

Chris Holmes wrote:
> Hi,
> This may not be a bug at all and, rather, a lack of understanding on my
> part; however ...
>
> If we have a directory structure of the following form:
> MyProject
> Parent (directory)
> parent.ecore
> parent.emf
> Child (directory)
> child.ecore
> child.emf
>
> Each Emfatic file defines a namespace commensurate with its location in
> the directory hierarchy:
> parent
> parent.child
>
> And each defines its own package and imports the namespace directly
> above it:
> parent (doesn't import anything)
> child (imports parent)
>
> If package Parent defines a class Thing and package Child extends this
> class as (say) AnotherThing then I can run a transformation
> (MyTransformation) using Ant to provide a reference to package Child and
> access the types Thing and AnotherThing via (e.g.)
> Target!Thing
> and
> Target!AnotherThing
>
> However, if package Child is empty or does not extend any of the classes
> provided in package Parent, say Child now introduces the class Strange,
> then using the same approach as above I find that:
> Target!Strange is resolved correctly, but
> Target!Thing can no longer be found.
>
> Is this behaviour to be expected?
>
> Regards
> Chris


--
Spread the word: http://www.eclipse.org/gmt/epsilon/spreadtheword
Follow Epsilon on Twitter: http://twitter.com/epsilonews
Re: Possible bug in ETL/Emfatic? [message #588018 is a reply to message #524034] Tue, 30 March 2010 12:45 Go to previous messageGo to next message
Eclipse User
Originally posted by: c.k.holmes.lboro.ac.uk

Hi Dimitris,
OK, thanks for clarifying for me.

It occurred to me that I could have made Child a child package of Parent
such that Child should be able to the Parent's parts (I could do this
with XMF), however I don't know the syntax for either Emfatic or eCore
(I spent a while searching the web, but didn't find anything useful). Do
you know if this is possible, and, if so, could you provide an example
of the syntax?

Best Wishes
Chris

Dimitris Kolovos wrote:
> Hi Chris,
>
> This is the expected behaviour. The Emfatic "import" statement is just a
> convenience mechanism so that you don't have to refer to external
> EClasses using fully-qualified names (i.e. including namespace URI). If
> you don't use (reference, extend) any EClasses from the imported
> (parent) metamodel, then when you do the Emfatic->Ecore transformation
> on the child metamodel, the "import" is not mapped to anything.
>
> A solution for this would be to allow Epsilon to load a model using a
> number of (instead of just one) unrelated metamodel URIs. This is
> something we've been pondering as a feature for some time now but didn't
> have a case study for. As a workaround you can use a third metamodel
> which imports and somehow references classes from both the parent and
> the child metamodels (even in abstract non-instantiable classes) and use
> this to load your models.
>
> Cheers,
> Dimitris
>
> Chris Holmes wrote:
>> Hi,
>> This may not be a bug at all and, rather, a lack of understanding on
>> my part; however ...
>>
>> If we have a directory structure of the following form:
>> MyProject
>> Parent (directory)
>> parent.ecore
>> parent.emf
>> Child (directory)
>> child.ecore
>> child.emf
>>
>> Each Emfatic file defines a namespace commensurate with its location
>> in the directory hierarchy:
>> parent
>> parent.child
>>
>> And each defines its own package and imports the namespace directly
>> above it:
>> parent (doesn't import anything)
>> child (imports parent)
>>
>> If package Parent defines a class Thing and package Child extends this
>> class as (say) AnotherThing then I can run a transformation
>> (MyTransformation) using Ant to provide a reference to package Child
>> and access the types Thing and AnotherThing via (e.g.)
>> Target!Thing
>> and
>> Target!AnotherThing
>>
>> However, if package Child is empty or does not extend any of the
>> classes provided in package Parent, say Child now introduces the class
>> Strange, then using the same approach as above I find that:
>> Target!Strange is resolved correctly, but
>> Target!Thing can no longer be found.
>>
>> Is this behaviour to be expected?
>>
>> Regards
>> Chris
>
>
Re: Possible bug in ETL/Emfatic? [message #588024 is a reply to message #588018] Tue, 30 March 2010 12:59 Go to previous message
Dimitrios Kolovos is currently offline Dimitrios Kolovos
Messages: 1776
Registered: July 2009
Senior Member
Hi Chris,

Section 1.2 of http://www.eclipse.org/gmt/epsilon/doc/articles/emfatic/
provides examples for defining sub-packages in Emfatic. (this is a
relatively new article so Google may not have picked it up yet)

Cheers,
Dimitris

Chris Holmes wrote:
> Hi Dimitris,
> OK, thanks for clarifying for me.
>
> It occurred to me that I could have made Child a child package of Parent
> such that Child should be able to the Parent's parts (I could do this
> with XMF), however I don't know the syntax for either Emfatic or eCore
> (I spent a while searching the web, but didn't find anything useful). Do
> you know if this is possible, and, if so, could you provide an example
> of the syntax?
>
> Best Wishes
> Chris
>
> Dimitris Kolovos wrote:
>> Hi Chris,
>>
>> This is the expected behaviour. The Emfatic "import" statement is just
>> a convenience mechanism so that you don't have to refer to external
>> EClasses using fully-qualified names (i.e. including namespace URI).
>> If you don't use (reference, extend) any EClasses from the imported
>> (parent) metamodel, then when you do the Emfatic->Ecore transformation
>> on the child metamodel, the "import" is not mapped to anything.
>>
>> A solution for this would be to allow Epsilon to load a model using a
>> number of (instead of just one) unrelated metamodel URIs. This is
>> something we've been pondering as a feature for some time now but
>> didn't have a case study for. As a workaround you can use a third
>> metamodel which imports and somehow references classes from both the
>> parent and the child metamodels (even in abstract non-instantiable
>> classes) and use this to load your models.
>>
>> Cheers,
>> Dimitris
>>
>> Chris Holmes wrote:
>>> Hi,
>>> This may not be a bug at all and, rather, a lack of understanding on
>>> my part; however ...
>>>
>>> If we have a directory structure of the following form:
>>> MyProject
>>> Parent (directory)
>>> parent.ecore
>>> parent.emf
>>> Child (directory)
>>> child.ecore
>>> child.emf
>>>
>>> Each Emfatic file defines a namespace commensurate with its location
>>> in the directory hierarchy:
>>> parent
>>> parent.child
>>>
>>> And each defines its own package and imports the namespace directly
>>> above it:
>>> parent (doesn't import anything)
>>> child (imports parent)
>>>
>>> If package Parent defines a class Thing and package Child extends
>>> this class as (say) AnotherThing then I can run a transformation
>>> (MyTransformation) using Ant to provide a reference to package Child
>>> and access the types Thing and AnotherThing via (e.g.)
>>> Target!Thing
>>> and
>>> Target!AnotherThing
>>>
>>> However, if package Child is empty or does not extend any of the
>>> classes provided in package Parent, say Child now introduces the
>>> class Strange, then using the same approach as above I find that:
>>> Target!Strange is resolved correctly, but
>>> Target!Thing can no longer be found.
>>>
>>> Is this behaviour to be expected?
>>>
>>> Regards
>>> Chris
>>
>>


--
Spread the word: http://www.eclipse.org/gmt/epsilon/spreadtheword
Follow Epsilon on Twitter: http://twitter.com/epsilonews
Previous Topic:Possible bug in ETL/Emfatic?
Next Topic:[Eugenia] FixGenModel leaves empty model, how to track down problem?
Goto Forum:
  


Current Time: Sat Sep 20 18:10:50 GMT 2014

Powered by FUDForum. Page generated in 0.03488 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software