Home » Modeling » EMF » genmodel - root packages problem(reference to package in other genmodel instead of additional root package desired, but impossible to resolve dependencies)
|
| Re: genmodel - root packages problem [message #1062038 is a reply to message #1062019] |
Wed, 05 June 2013 14:19   |
 Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Till,
Comments below.
On 05/06/2013 4:01 PM, Till Fischer wrote:
> Hi,
>
> I ran into a problem when playing aroung with EMF ecore models and
> generated editors.
>
> The essential part can be abstracted to the following example: I've
> got an "overall" model consisting of two EClasses EC1 and EC2. EC1
> references EC2. The next thing is important: I'd like to provide the
> possibility to go "backwards" in every case, thus, there is an
> "opposite" reference from EC2 to EC1 (this reference is maintained
> automatically). As a class diagram this would look like this:
>
>
> |
> ------- | -------
> | EC1 | | | EC2 |
> +-----+ * | 1 +-----+
> | | ----------> | |
> ------- | -------
> | "left" | "right"
> |
> In reality the model is more complex, and I decided to have different
> ecore models to describe the "left" and the "right" domain. Now the
> problem: I cannot create two independent generator models (genmodel)
> for "left" and "right".
No, though Xcore is a little more permissive in this regard, so perhaps
switching to Xcore will help.
> I'd like to have a generator model for "left" that only references the
> genmodel for "right" and vice versa. Unfortunately this is not
> possible, because when creating the genmodel for "left" I would
> already need the genmodel for "right" (and the other way around). In
> theory this construct shouldn't be "logically impossible" (just alone
> because it is possible to define respective ecore models). Has anyone
> a solution for my issue?
I think it's possible with models specified in Xcore, but even then, I'm
pretty sure they need to be in the same project. Otherwise the bundles
would have to be mutually dependent and that's not possible either.
>
> While writing this I'm thinking of creating a "dummy" genmodel that
> includes all referenced packages as additional root packages in the
> "New EMF Generator Model" wizard for "left". Then I could create the
> "right" genmodel as desired, delete the dummy, and finally create the
> desired version of "left"... this could actually work... kinda hacky
> though...
In the end you have to accept that mutual dependency are just that,
neither is independent of the other and that limits how you can separate
them into bundles and into separate models.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: genmodel - root packages problem [message #1062093 is a reply to message #1062063] |
Wed, 05 June 2013 23:04 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Till,
Comments below.
On 05/06/2013 5:47 PM, Till Fischer wrote:
> Hi, thanks for your hint with Xcore; I'm going to check that out.
>
> Regarding my own "solution": I actually made it working... exactly as
> described in my first post (deleting and re-creating the genmodel)
> :twisted:
> Indeed, there will always be mutual dependencies, and they caused some
> trouble in the beginning... But it was possible to solve it: I changed
> the "Directory" and "Plug-in ID" for Model and Edit in the genmodels'
> root so that respective output is generated into a common project
> (this was desired anyway; I don't see any reason for having separate
> projects/plugins for Model and Edit code in my case).
So you could just have a single GenModel that generates those things
into the same bundles.
> Editor artifacts however are generated into separate projects for
> every "domain" ("left, "right" in my example).
The editors only depend on the model and edit bundles, not on each
other. In fact, if you look closely at the editors, they're mostly
identical (and even the parts that are different aren't necessarily so
because each can find the item providers for any models needed in the
registry) so you could get by with just a single editor...
>
> As a result I have one genmodel for each "domain", but no package in
> respective ecore models is included in more than one genmodel.
> Furtermore, I have one plugin that provides everything necessary to
> "work" with any model, and an additional plugin for every "domain"
> that provides the respective editor. And not a single warning in the
> whole workspace :p
> Remains the question why the wizard and default settings for EMF
> generator models are so awkward... It took me a whole day to figure
> this out...
As you ended up noticing, the generated models must necessarily be in
the same bundle, so requiring a single GenModel is a natural fit...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: genmodel - root packages problem [message #1062136 is a reply to message #1062093] |
Thu, 06 June 2013 07:51 |
Till F.
Messages: 58
Registered: August 2012 |
Member |
|
|
Ed Merks wrote on Wed, 05 June 2013 19:04So you could just have a single GenModel that generates those things into the same bundles.
I think this would force me to have one plugin providing all editors (or a single editor as you already suggested), wouldn't it? The problem is that this would break the separation I'm trying to achive by having different ecore models for different domains in my "overall" model. In my opinion it makes pretty much sense to have different editors that can be distributed separately. And because I don't want replicated code, everything that is shared by different editors should go into a plugin, which will be a dependency of all editor plugins. Is it possible to achieve this using a single genmodel?
/edit:
Ed Merks wrote on Wed, 05 June 2013 19:04In fact, if you look closely at the editors, they're mostly identical (and even the parts that are different aren't necessarily so because each can find the item providers for any models needed in the registry)
This is only true if I don't customize the editor. But this is going to happen, of course. The editor for "left" will be completely different from the editor for "right".
[Updated on: Thu, 06 June 2013 07:58] Report message to a moderator |
|
|
| Re: genmodel - root packages problem [message #1062139 is a reply to message #1062136] |
Thu, 06 June 2013 08:08 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Till,
Comments below.
On 06/06/2013 9:51 AM, Till Fischer wrote:
> Ed Merks wrote on Wed, 05 June 2013 19:04
>> So you could just have a single GenModel that generates those things
>> into the same bundles.
>
>
> I think this would force me to have one plugin providing all editors
> (or a single editor as you already suggested), wouldn't it?
Yes.
> The problem is that this would break the separation I'm trying to
> achive by having different ecore models for different domains in my
> "overall" model.
It doesn't sound like you have much separation right now already, with
both models generated into one bundle.
> In my opinion it makes pretty much sense to have different editors
> that can be distributed separately.
Or have a common editor that's registered for two different file
extensions so only those registrations are distributed separately. And
given the bidirectional nature of references between the models, it's
hard to imagine how you won't always need both editors...
> And because I don't want replicated code, everything that is shared by
> different editors should go into a plugin, which will be a dependency
> of all editor plugins. Is it possible to achieve this using a single
> genmodel?
You'd end up with two editors in one bundle. But as I said above, how
does it make sense to provide only a single editor when that editor will
not be able to edit the complete model because it has bidirectional
references to things for which there is no editor?
I suspect the whole problem boils down to whether that bidirectional
reference was a good design choice. It's often the case that a
bidirectional reference seems very convenient but makes little sense.
E.g., EClass.eSuperTypes is modeled but it's not bidirectional, so you
can't determine all the subclasses of an EClass, which would be very
convenient feature to have, but it makes no sense because you can't
expect an EClass to serialize references to all subclasses because that
collection is unbounded...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: genmodel - root packages problem [message #1062147 is a reply to message #1062139] |
Thu, 06 June 2013 08:49 |
Till F.
Messages: 58
Registered: August 2012 |
Member |
|
|
Ed Merks wrote on Thu, 06 June 2013 04:08
You'd end up with two editors in one bundle. But as I said above, how
does it make sense to provide only a single editor when that editor will
not be able to edit the complete model because it has bidirectional
references to things for which there is no editor?
It does make sense: let's assume the "right" domain describes the architecture of microprocessors. Microprocessor-expert Jack builds corresponding model instances (own file extension). The "left" domain describes the layout of circuit boards. These may contain a microprocessor. Board-expert Anna builds corresponding model instaces (another file extension), but she doesn't know anything about microprocessor-internals. She just references the model provided by Jack (who doesn't know anything about Annas board). The editor of Anna shouldn't allow changes in the "right" domain, as Jack shouldn't be able to do anything in the "left" domain. Now there's Tom, the test-expert. He doesn't change anything Anna or Jack did, but he needs all internal information in order to build concrete test cases. He works with the "overall" model. This already works without writing a single line of code, apart from the fact that both editors allow modifications in both domains. I expect that this can be changed easily.
This example doesn't give a good reason to have a bidirectional reference though. I'm not sure whether this one will be required, but actually a "backwards" reference is never required in a model, since corresponding references could be calculated manually. I made the design decision that there is absolutely no reference without a way back. This will make life a lot easier later, when it is about building automation tools that work with the models, or Model-To-X transformations.
|
|
|
| Re: genmodel - root packages problem [message #1062198 is a reply to message #1062147] |
Thu, 06 June 2013 13:27 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Till,
Comments below.
On 06/06/2013 10:49 AM, Till Fischer wrote:
> Ed Merks wrote on Thu, 06 June 2013 04:08
>> You'd end up with two editors in one bundle. But as I said above,
>> how does it make sense to provide only a single editor when that
>> editor will not be able to edit the complete model because it has
>> bidirectional references to things for which there is no editor?
>
> It does make sense: let's assume the "right" domain describes the
> architecture of microprocessors. Microprocessor-expert Jack builds
> corresponding model instances (own file extension). The "left" domain
> describes the layout of circuit boards. These may contain a
> microprocessor. Board-expert Anna builds corresponding model instaces
> (another file extension), but she doesn't know anything about
> microprocessor-internals. She just references the model provided by
> Jack (who doesn't know anything about Annas board).
So Annas model will reference Jack's model and both models will be in
the workspace?
> The editor of Anna shouldn't allow changes in the "right" domain, as
> Jack shouldn't be able to do anything in the "left" domain.
But both files are present in the workspace?
> Now there's Tom, the test-expert. He doesn't change anything Anna or
> Jack did, but he needs all internal information in order to build
> concrete test cases. He works with the "overall" model. This already
> works without writing a single line of code, apart from the fact that
> both editors allow modifications in both domains. I expect that this
> can be changed easily.
>
> This example doesn't give a good reason to have a bidirectional
> reference though.
I'm not so convinced. What about Anna's 300 sisters? As each one
references Jack's model, the bidirectional reference implies Jacks model
is modified to contain the reference references. That can't be good...
> I'm not sure whether this one will be required, but actually a
> "backwards" reference is never required in a model, since
> corresponding references could be calculated manually. I made the
> design decision that there is absolutely no reference without a way
> back. This will make life a lot easier later, when it is about
> building automation tools that work with the models, or Model-To-X
> transformations.
This really does sound more like the EClass.eSuperTypes thing where
backward references, finding all subclasses is an indexing problem, not
something we want stored in the EClass itself...
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: genmodel - root packages problem [message #1062693 is a reply to message #1062198] |
Mon, 10 June 2013 12:00 |
Till F.
Messages: 58
Registered: August 2012 |
Member |
|
|
Ed Merks wrote on Thu, 06 June 2013 09:27So Annas model will reference Jack's model and both models will be in the workspace?
Yes. One could say that Jack's model will be "imported" by Anna.
Ed Merks wrote on Thu, 06 June 2013 09:27
I'm not so convinced. What about Anna's 300 sisters? As each one
references Jack's model, the bidirectional reference implies Jacks model
is modified to contain the reference references.
This is a good point, even though the final scenario won't be that Anna's 300 sisters share one and the same model, but Jack would give his "instance" to every sister separately (hand signed and personally). But the actual problem that Anna's reference will always imply a slight change in Jack's model still remains...
Ed Merks wrote on Thu, 06 June 2013 09:27This really does sound more like the EClass.eSuperTypes thing where
backward references, finding all subclasses is an indexing problem, not
something we want stored in the EClass itself...
And probably you are right with this, too.
Altogether: the backwards reference might be unwanted... it does more harm than it helps. On the other hand, I like the idea of having a the "overall" meta-model defined that tight...
I'm going to think about it. And thanks for your thoughts!
[Updated on: Mon, 10 June 2013 12:02] Report message to a moderator |
|
|
Goto Forum:
Current Time: Tue Apr 16 22:35:57 GMT 2024
Powered by FUDForum. Page generated in 1.87932 seconds |
] 
Search
Help
Register
Login
Home
