Home » Modeling » EMF » trouble with nested packages
| trouble with nested packages [message #501102] |
Tue, 01 December 2009 04:11  |
 Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Hi,
I'm having some trouble with nested packages. I have a metamodel for a
language that's fairly big, so has been broken up into several nested
packages. I've given the top-level package the nsURI
http://express.ecore, then the subpackages nsURI values like
http://express.ecore#//core and so on.
My problem comes when I am trying to process models instantiated using
this metamodel. My processing program (a model transformation engine, so
not specific to my express metamodel) loads up the top-level ecore file
(the transformation basically has an import statement), and retrieves
one of the EClasses I'm interested in, but when it tries to do a
comparison (specifically an isInstance() call) with an object as loaded
in from the model, the classes are incompatible. Specifically, the model
object, under reflection, is an instance of an EClass coming from
http://express.ecore#//core The transformation engine, though, loaded
up http://express.ecore and navigated down to find the EClass by name in
a subpackage, and ended up with a different EClass object.
Does that make sense? What am I doing wrong? Have I set up my model
wrongly (in terms of nsURIs for the different packages)? Is the
transformation engine doing something wrong?
Cheers,
Jim.
|
|
|
| Re: trouble with nested packages [message #501168 is a reply to message #501102] |
Tue, 01 December 2009 11:41  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Jim,
Comments below.
Jim Steel wrote:
>
> Hi,
>
> I'm having some trouble with nested packages. I have a metamodel for a
> language that's fairly big, so has been broken up into several nested
> packages. I've given the top-level package the nsURI
> http://express.ecore, then the subpackages nsURI values like
> http://express.ecore#//core and so on.
You'll notice that I often mention how much I dislike nested packages
because they're unnecessary syntactic sugar and often end up causing
problems because some aspect of the framework doesn't work perfectly for
them.
>
> My problem comes when I am trying to process models instantiated using
> this metamodel. My processing program (a model transformation engine,
> so not specific to my express metamodel) loads up the top-level ecore
> file (the transformation basically has an import statement), and
> retrieves one of the EClasses I'm interested in, but when it tries to
> do a comparison (specifically an isInstance() call) with an object as
> loaded in from the model, the classes are incompatible. Specifically,
> the model object, under reflection, is an instance of an EClass coming
> from http://express.ecore#//core The transformation engine, though,
> loaded up http://express.ecore and navigated down to find the EClass
> by name in a subpackage, and ended up with a different EClass object.
This doesn't even sound related to package nesting.
>
> Does that make sense?
Yes.
> What am I doing wrong?
Likely the expectation is wrong. Loading an Ecore instance from a
resource verses using the generated runtime instance accessed by
XyzPackage.eINSTANCE yields two different instances that while being
structurally equal are nevertheless two different instances. Creating
instances from either of these models don't produce an instance that
conforms to the other.
> Have I set up my model wrongly (in terms of nsURIs for the different
> packages)? Is the transformation engine doing something wrong?
To access the runtime instance, one should use the nsURI of the package
to find it, even when using ResourceSet.getResource, because that will
try to resolve the nsURI in the package registry, which is what you
want. Loading and Ecore instance from a physical URI is mostly likely to
get you an instance that's different from the runtime instance, unless
some URI mappings in the local URI converter are helping deal with that.
>
> Cheers,
>
> Jim.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: trouble with nested packages [message #501390 is a reply to message #501168] |
Wed, 02 December 2009 06:57 |
Jim Steel
Messages: 54
Registered: July 2009 |
Member |
|
|
Comments below.
Ed Merks wrote:
> Jim,
>
> Comments below.
>
> Jim Steel wrote:
>>
>> Hi,
>>
>> I'm having some trouble with nested packages. I have a metamodel for a
>> language that's fairly big, so has been broken up into several nested
>> packages. I've given the top-level package the nsURI
>> http://express.ecore, then the subpackages nsURI values like
>> http://express.ecore#//core and so on.
> You'll notice that I often mention how much I dislike nested packages
> because they're unnecessary syntactic sugar and often end up causing
> problems because some aspect of the framework doesn't work perfectly for
> them.
I did notice that, but I disagree that they are unnecessary syntactic
sugar. The ecore metamodel for the language I'm using (not defined by
me) has almost 200 class or datatype definitions. The alternatives to
using subpackages, as far as I can see, are
- put all the type definitions in a single flat namespace, rendering the
language definition incomprehensible to anyone trying to understand it
- put the different packages in separate ecore files, which defies the
logical idea that they constitute a single language. As I discuss below,
when I want to import this language, I want to import a single language,
not a series of interrelated parts.
Regardless...
>>
>> My problem comes when I am trying to process models instantiated using
>> this metamodel. My processing program (a model transformation engine,
>> so not specific to my express metamodel) loads up the top-level ecore
>> file (the transformation basically has an import statement), and
>> retrieves one of the EClasses I'm interested in, but when it tries to
>> do a comparison (specifically an isInstance() call) with an object as
>> loaded in from the model, the classes are incompatible. Specifically,
>> the model object, under reflection, is an instance of an EClass coming
>> from http://express.ecore#//core The transformation engine, though,
>> loaded up http://express.ecore and navigated down to find the EClass
>> by name in a subpackage, and ended up with a different EClass object.
> This doesn't even sound related to package nesting.
I think it is. The engine works fine (and has done for many years) for
all my other ecore models.
>>
>> Does that make sense?
> Yes.
>> What am I doing wrong?
> Likely the expectation is wrong. Loading an Ecore instance from a
> resource verses using the generated runtime instance accessed by
> XyzPackage.eINSTANCE yields two different instances that while being
> structurally equal are nevertheless two different instances. Creating
> instances from either of these models don't produce an instance that
> conforms to the other.
I understand that.
>> Have I set up my model wrongly (in terms of nsURIs for the different
>> packages)? Is the transformation engine doing something wrong?
> To access the runtime instance, one should use the nsURI of the package
> to find it, even when using ResourceSet.getResource, because that will
> try to resolve the nsURI in the package registry, which is what you
> want. Loading and Ecore instance from a physical URI is mostly likely to
> get you an instance that's different from the runtime instance, unless
> some URI mappings in the local URI converter are helping deal with that.
The transformation engine (for which I have source) is loading up the
ecore model using the nsURI of a package, but it is using the nsURI of
the containing package, not of the contained package (importing an ecore
model in the transformation language imports not only classes in that
package, but also classes in subpackages). What it does is to build up a
mapping from EClass names to EClass instances. This works fine for
classes in the package directly.
My problem is that when the transformation engine code navigates down
through the eSubPackage relationship (building up a mapping from EClass
names to EClass instances, it ends up in finding different EClass
instances than those that would be found (presumably) if I loaded up the
resource directly from the nsURI of the contained package.
So, rather than navigating down the eSubPackages-eClassifiers link, I
should just navigate the eSubPackages link, find the nsURIs of contained
packages, and load those up?
It seems a strange thing to do - I might have thought that it would be
guaranteed somehow that the two might return the same objects?
>>
>> Cheers,
>>
>> Jim.
|
|
|
| Re: trouble with nested packages [message #501471 is a reply to message #501390] |
Wed, 02 December 2009 13:46 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Jim,
Comments below.
Jim Steel wrote:
>
> Comments below.
>
> Ed Merks wrote:
>> Jim,
>>
>> Comments below.
>>
>> Jim Steel wrote:
>>>
>>> Hi,
>>>
>>> I'm having some trouble with nested packages. I have a metamodel for
>>> a language that's fairly big, so has been broken up into several
>>> nested packages. I've given the top-level package the nsURI
>>> http://express.ecore, then the subpackages nsURI values like
>>> http://express.ecore#//core and so on.
>> You'll notice that I often mention how much I dislike nested packages
>> because they're unnecessary syntactic sugar and often end up causing
>> problems because some aspect of the framework doesn't work perfectly
>> for them.
>
> I did notice that, but I disagree that they are unnecessary syntactic
> sugar. The ecore metamodel for the language I'm using (not defined by
> me) has almost 200 class or datatype definitions. The alternatives to
> using subpackages, as far as I can see, are
> - put all the type definitions in a single flat namespace, rendering
> the language definition incomprehensible to anyone trying to
> understand it
> - put the different packages in separate ecore files, which defies the
> logical idea that they constitute a single language.
I disagree with that premise. In the end, you end up Java structure
that makes them separate but related packages. The Ecore file structure
could reflect that too. One could even put a bunch of them at the root
of the same file, but that's just as likely to cause problems.
> As I discuss below, when I want to import this language, I want to
> import a single language, not a series of interrelated parts.
It's a very fine point, but of course we're all entitled to our
opinions. It has no semantic significance to nest packages and I think
that's the definition of syntactic sugar. Given the choice, I would not
have provided this feature, especially given that's it's a recurring
source of problems...
>
> Regardless...
>
>>>
>>> My problem comes when I am trying to process models instantiated
>>> using this metamodel. My processing program (a model transformation
>>> engine, so not specific to my express metamodel) loads up the
>>> top-level ecore file (the transformation basically has an import
>>> statement), and retrieves one of the EClasses I'm interested in, but
>>> when it tries to do a comparison (specifically an isInstance() call)
>>> with an object as loaded in from the model, the classes are
>>> incompatible. Specifically, the model object, under reflection, is
>>> an instance of an EClass coming from http://express.ecore#//core
>>> The transformation engine, though, loaded up http://express.ecore
>>> and navigated down to find the EClass by name in a subpackage, and
>>> ended up with a different EClass object.
>> This doesn't even sound related to package nesting.
>
> I think it is. The engine works fine (and has done for many years) for
> all my other ecore models.
As I said, nesting is a recurring source of problems...
>
>>>
>>> Does that make sense?
>> Yes.
>>> What am I doing wrong?
>> Likely the expectation is wrong. Loading an Ecore instance from a
>> resource verses using the generated runtime instance accessed by
>> XyzPackage.eINSTANCE yields two different instances that while being
>> structurally equal are nevertheless two different instances.
>> Creating instances from either of these models don't produce an
>> instance that conforms to the other.
>
> I understand that.
>
>>> Have I set up my model wrongly (in terms of nsURIs for the different
>>> packages)? Is the transformation engine doing something wrong?
>> To access the runtime instance, one should use the nsURI of the
>> package to find it, even when using ResourceSet.getResource, because
>> that will try to resolve the nsURI in the package registry, which is
>> what you want. Loading and Ecore instance from a physical URI is
>> mostly likely to get you an instance that's different from the
>> runtime instance, unless some URI mappings in the local URI converter
>> are helping deal with that.
>
> The transformation engine (for which I have source) is loading up the
> ecore model using the nsURI of a package, but it is using the nsURI of
> the containing package, not of the contained package (importing an
> ecore model in the transformation language imports not only classes in
> that package, but also classes in subpackages). What it does is to
> build up a mapping from EClass names to EClass instances. This works
> fine for classes in the package directly.
Of course names can be duplicated across packages, but that would be
another issue...
>
> My problem is that when the transformation engine code navigates down
> through the eSubPackage relationship (building up a mapping from
> EClass names to EClass instances, it ends up in finding different
> EClass instances than those that would be found (presumably) if I
> loaded up the resource directly from the nsURI of the contained package.
I'm not sure how that's possible. It shouldn't be possible to reach
anything but other generated subpackages from a generated package.
>
> So, rather than navigating down the eSubPackages-eClassifiers link, I
> should just navigate the eSubPackages link, find the nsURIs of
> contained packages, and load those up?
I guess. I don't understand the source of the problem though. One thing
to keep in mind is that the generator doesn't generate empty packages,
i.e., packages without classifier, even if they have subpackages.
There's a bugzilla to provide an option, but a simple workaround is to
add a dummy EDataType.
>
> It seems a strange thing to do - I might have thought that it would be
> guaranteed somehow that the two might return the same objects?
I would have thought so too. I can't imagine how it would reach a
different instance, but the debugger I'm sure would shed light on the
details...
>
>>>
>>> Cheers,
>>>
>>> Jim.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: trouble with nested packages [message #501569 is a reply to message #501390] |
Wed, 02 December 2009 20:02 |
Timothy Marc
Messages: 547
Registered: July 2009 |
Senior Member |
|
|
Hi Jim,
well' my metamodel has approximately 100 classes, and i structure them
in hierarchical packages. But before generating code for it, i duplicate
the ecore file and flatten all subpackages into the root package. With
this workflow it is possible to keep a manageable structure of the model
and to sail around the problems and inconveniences of nested pasckages
(e.g. a seperate factory for each package).
Cheers Timothy
Jim Steel schrieb:
>
> Comments below.
>
> Ed Merks wrote:
>> Jim,
>>
>> Comments below.
>>
>> Jim Steel wrote:
>>>
>>> Hi,
>>>
>>> I'm having some trouble with nested packages. I have a metamodel for
>>> a language that's fairly big, so has been broken up into several
>>> nested packages. I've given the top-level package the nsURI
>>> http://express.ecore, then the subpackages nsURI values like
>>> http://express.ecore#//core and so on.
>> You'll notice that I often mention how much I dislike nested packages
>> because they're unnecessary syntactic sugar and often end up causing
>> problems because some aspect of the framework doesn't work perfectly
>> for them.
>
> I did notice that, but I disagree that they are unnecessary syntactic
> sugar. The ecore metamodel for the language I'm using (not defined by
> me) has almost 200 class or datatype definitions. The alternatives to
> using subpackages, as far as I can see, are
> - put all the type definitions in a single flat namespace, rendering the
> language definition incomprehensible to anyone trying to understand it
> - put the different packages in separate ecore files, which defies the
> logical idea that they constitute a single language. As I discuss below,
> when I want to import this language, I want to import a single language,
> not a series of interrelated parts.
>
> Regardless...
>
>>>
>>> My problem comes when I am trying to process models instantiated
>>> using this metamodel. My processing program (a model transformation
>>> engine, so not specific to my express metamodel) loads up the
>>> top-level ecore file (the transformation basically has an import
>>> statement), and retrieves one of the EClasses I'm interested in, but
>>> when it tries to do a comparison (specifically an isInstance() call)
>>> with an object as loaded in from the model, the classes are
>>> incompatible. Specifically, the model object, under reflection, is an
>>> instance of an EClass coming from http://express.ecore#//core The
>>> transformation engine, though, loaded up http://express.ecore and
>>> navigated down to find the EClass by name in a subpackage, and ended
>>> up with a different EClass object.
>> This doesn't even sound related to package nesting.
>
> I think it is. The engine works fine (and has done for many years) for
> all my other ecore models.
>
>>>
>>> Does that make sense?
>> Yes.
>>> What am I doing wrong?
>> Likely the expectation is wrong. Loading an Ecore instance from a
>> resource verses using the generated runtime instance accessed by
>> XyzPackage.eINSTANCE yields two different instances that while being
>> structurally equal are nevertheless two different instances. Creating
>> instances from either of these models don't produce an instance that
>> conforms to the other.
>
> I understand that.
>
>>> Have I set up my model wrongly (in terms of nsURIs for the different
>>> packages)? Is the transformation engine doing something wrong?
>> To access the runtime instance, one should use the nsURI of the
>> package to find it, even when using ResourceSet.getResource, because
>> that will try to resolve the nsURI in the package registry, which is
>> what you want. Loading and Ecore instance from a physical URI is
>> mostly likely to get you an instance that's different from the runtime
>> instance, unless some URI mappings in the local URI converter are
>> helping deal with that.
>
> The transformation engine (for which I have source) is loading up the
> ecore model using the nsURI of a package, but it is using the nsURI of
> the containing package, not of the contained package (importing an ecore
> model in the transformation language imports not only classes in that
> package, but also classes in subpackages). What it does is to build up a
> mapping from EClass names to EClass instances. This works fine for
> classes in the package directly.
>
> My problem is that when the transformation engine code navigates down
> through the eSubPackage relationship (building up a mapping from EClass
> names to EClass instances, it ends up in finding different EClass
> instances than those that would be found (presumably) if I loaded up the
> resource directly from the nsURI of the contained package.
>
> So, rather than navigating down the eSubPackages-eClassifiers link, I
> should just navigate the eSubPackages link, find the nsURIs of contained
> packages, and load those up?
>
> It seems a strange thing to do - I might have thought that it would be
> guaranteed somehow that the two might return the same objects?
>
>>>
>>> Cheers,
>>>
>>> Jim.
|
|
|
Goto Forum:
Current Time: Fri Apr 19 08:53:20 GMT 2024
Powered by FUDForum. Page generated in 0.02401 seconds |
] 
Search
Help
Register
Login
Home
