Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » trouble with nested packages
trouble with nested packages [message #501102] Tue, 01 December 2009 04:11 Go to next message
Jim Steel is currently offline Jim SteelFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30623
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.
Re: trouble with nested packages [message #501390 is a reply to message #501168] Wed, 02 December 2009 06:57 Go to previous messageGo to next message
Jim Steel is currently offline Jim SteelFriend
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 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 30623
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.
Re: trouble with nested packages [message #501569 is a reply to message #501390] Wed, 02 December 2009 20:02 Go to previous message
Timothy Marc is currently offline Timothy MarcFriend
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.
Previous Topic:Command to put to an EMap ?
Next Topic:[Teneo] library example editor
Goto Forum:
  


Current Time: Wed Nov 13 09:29:52 GMT 2019

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

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

Back to the top