Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Indirectly referenced Generator Model required although unnecessary
Indirectly referenced Generator Model required although unnecessary [message #758562] Wed, 23 November 2011 16:53 Go to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi,

suppose I have 3 Ecore meta-models A, B and C,
with B referencing model elements from A
and with C referencing elements from B (i.e. A <- B <- C).

When I create the genmodel for B, I naturally have to supply A's genmodel
("Referenced Generator Models").
However when creating the genmodel for C, I not only have to select B's genmodel
but also A's, although C does not use any elements from it.
After code generation I can safely remove C's dependency to A from MANIFEST.MF
without getting compiler/runtime errors.

So my question is, why does the Generator require this indirect
(and in my eyes, unnecessary) dependency?
The reason I ask is that in the target environment A will not be accessible from
"outside" (i.e. from C), but only from B which can be seen as an "export interface"
for A, providing access to some public features.
The genmodel for A would thus not be available to the "outside" aswell.


Regards,
Tim
Re: Indirectly referenced Generator Model required although unnecessary [message #758565 is a reply to message #758562] Wed, 23 November 2011 17:24 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33216
Registered: July 2009
Senior Member
Tim,

Comments below.

On 23/11/2011 5:53 PM, Tim Schaefer wrote:
> Hi,
>
> suppose I have 3 Ecore meta-models A, B and C,
> with B referencing model elements from A
> and with C referencing elements from B (i.e. A <- B <- C).
>
> When I create the genmodel for B, I naturally have to supply A's genmodel
> ("Referenced Generator Models").
> However when creating the genmodel for C, I not only have to select
> B's genmodel
> but also A's, although C does not use any elements from it.
What's the nature of the references you mentioned?
> After code generation I can safely remove C's dependency to A from
> MANIFEST.MF
> without getting compiler/runtime errors.
Does the B export its dependencies on A? Often people don't like to do
that and change it...
>
> So my question is, why does the Generator require this indirect
> (and in my eyes, unnecessary) dependency?
> The reason I ask is that in the target environment A will not be
> accessible from
> "outside" (i.e. from C), but only from B which can be seen as an
> "export interface"
> for A, providing access to some public features.
Can you elaborate on that?
> The genmodel for A would thus not be available to the "outside" aswell.
In any case, you can modify the manifest and it won't be changed
afterward...
>
>
> Regards,
> Tim
>


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Indirectly referenced Generator Model required although unnecessary [message #758581 is a reply to message #758565] Wed, 23 November 2011 18:20 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi Ed,

thanks for your fast reply.

> What's the nature of the references you mentioned?
EReferences with EType set to an EClass of the referenced model.
They delegate feature-queries (derived estructuralfeatures) to the referenced EObject.

> Does the B export its dependencies on A? Often people don't like to do
> that and change it...
No, it doesn't export them.

> In any case, you can modify the manifest and it won't be changed afterward...
Sure, but it might be possible that A's genmodel is not available in the future
(e.g. not visible for C) and then I could not reload C's genmodel.

Does the Generator Model require the indirectly referenced genmodel or is this just
a requirement of the Model Importer wizard?
If the latter is the case, maybe I could write my own model importer and override this behavior?


Regards,
Tim
Re: Indirectly referenced Generator Model required although unnecessary [message #758721 is a reply to message #758581] Thu, 24 November 2011 11:48 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33216
Registered: July 2009
Senior Member
Tim,

Comments below.

On 23/11/2011 7:20 PM, Tim Schaefer wrote:
> Hi Ed,
>
> thanks for your fast reply.
>
>> What's the nature of the references you mentioned?
> EReferences with EType set to an EClass of the referenced model.
So interfaces will definitely expose the types of the accessor methods,
right?
> They delegate feature-queries (derived estructuralfeatures) to the
> referenced EObject.
So the implementation classes make use of the accessor methods...
>
>> Does the B export its dependencies on A? Often people don't like to do
>> that and change it...
> No, it doesn't export them.
In my experience, the compiler will complain about classes indirectly
referenced by a used class needing to be be on the classpath...
>
>> In any case, you can modify the manifest and it won't be changed
>> afterward...
> Sure, but it might be possible that A's genmodel is not available in
> the future
> (e.g. not visible for C) and then I could not reload C's genmodel.
It seems to me that B has methods whose types reveal A's generated
interfaces so any changes to A will be apparent...
>
> Does the Generator Model require the indirectly referenced genmodel or
> is this just
> a requirement of the Model Importer wizard?
It does currently require them. You could try deleting the
usedGenPackage and see how unhappy that makes the generator...
> If the latter is the case, maybe I could write my own model importer
> and override this behavior?
Anyone using your model will necessarily be able to traverse any
dependencies and will see the closure of all models. They will see A
whether you like it or not, and can create dependencies on it such that
if you change it, they will be broken...
>
>
> Regards,
> Tim


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Indirectly referenced Generator Model required although unnecessary [message #758740 is a reply to message #758721] Thu, 24 November 2011 12:53 Go to previous messageGo to next message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi Ed,

the three models are really decoupled in a way that C does not see any types of A.
It just accesses attributes of Bs objects and B internally delegates the requests.

Anyway, I think you're right, A can not be hidden from the overall classpath,
so my consideration about A being unaccessible makes no sense.

Thanks for your time.

Regards,
Tim
Re: Indirectly referenced Generator Model required although unnecessary [message #758750 is a reply to message #758740] Thu, 24 November 2011 13:31 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33216
Registered: July 2009
Senior Member
Tim,

Comments below.

On 24/11/2011 1:53 PM, Tim Schaefer wrote:
> Hi Ed,
>
> the three models are really decoupled in a way that C does not see any
> types of A.
Hmmm.
> It just accesses attributes of Bs objects and B internally delegates
> the requests.
Before you mentioned references in B's classes referring to classes in
A. I don't see how that's manifested in the generated API in a way
that hides A.
>
> Anyway, I think you're right, A can not be hidden from the overall
> classpath,
No, it clearly needs to be there...
> so my consideration about A being unaccessible makes no sense.
In general it might be a hidden implementation detail (though I don't
see how that's possible with references to classes in A) but, as I said,
the GenModel and Ecore models will definitely reveal the existence of A
no matter what you do...
>
> Thanks for your time.
>
> Regards,
> Tim


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: Indirectly referenced Generator Model required although unnecessary [message #758804 is a reply to message #758750] Thu, 24 November 2011 15:40 Go to previous message
Tim Schaefer is currently offline Tim SchaeferFriend
Messages: 49
Registered: June 2011
Location: Marburg, Germany
Member
Hi Ed,

sorry, the term "internal" was misleading. B's classes reference classes from A,
so they have getter/setter for these. But the classes from C don't use these getters/setters,
they only access B's attributes.
If I intentionally remove C's dependency to A, classes in C can see B's accessors
for the elements of A, but they are not "usable" for them since the types are unknown to them.

Anyway, you are right, all plugins are needed in the classpath so it doesn't really
matter whether C can see A.


Regards,
Tim
Previous Topic:[EMF Compare]Problem getting the text diff popup for a string EAttribute
Next Topic:Does it make sense to run headless Eclipse as EMF services back end?
Goto Forum:
  


Current Time: Mon Sep 23 02:35:21 GMT 2024

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

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

Back to the top