It's all about the answers!

Ask a question

Problems generating component models using the gentools on M


Igor Foox (41) | asked Aug 22 '07, 2:48 p.m.
When moving from M1 to M2 I had some problems generating the model on
M2. The problem was that my model referenced other models (Repository
and SCM) and in the EPackage initialization code there were calls like:

theRepositoryPackage.getContributorHandleFacade()

but there was only theRepositoryPackage.getContributorHandle() available
in that class.

After talking to Christopher Daly about this, he mentioned that this is
a problem with how the codegen was done for M2 and will probably be
fixed in future integration builds.
The solution he suggested for fixing it for now was to manually modify
my generated code to call getFooHandle() instead of getFooHandleFacade()
and that works.

Chris, please correct me if I'm getting any of this wrong.

Thanks,
Igor Foox

2 answers



permanent link
Sachin Patel (10123) | answered Aug 23 '07, 7:59 a.m.
JAZZ DEVELOPER
We have a model and are using the codegen tools.

Chris Daly wrote:
Igor Foox wrote:
...
Chris, please correct me if I'm getting any of this wrong.


This is basically right but I'll add a few details to clarify.

First, to encounter the problem Igor is describing you would have to go
beyond the JazzTalk walkthrough. Specifically you would have to add an
EReference in your model that refers to a type in another storage model
(for instance it looks like Igor made an EReference to the Contributor
type in the repository model).

What really happened to cause this is complicated, but it boils down to
us moving from EMF 2.3.0M7 to EMF 2.3.0(final) for the Jazz M2 release.
The old codegen doesn't work with the final 2.3.0 EMF, but the new
codegen has slightly different generation patterns. The components that
ship with Jazz (repository, build, workitem, etc...) have regenerated
their models, but this was done after M2. So any post-M2 weekly build
should include the missing methods, but I don't see a post-M2 weekly
build on jazz.net yet.

I wasn't sure how fast people would pick up on JazzTalk and start trying
to go beyond it by developing their own storage models, but it's
happening more quickly than I expected. :-) I'm curious to know how
many people out there are building storage models. It would help me to
plan what I can do to best help you. So if you want to be counted in my
"storage model developer census", please reply to this thread and
mention that you are developing a storage model.

One more thing: As Igor pointed out, the methods that don't resolve have
names like getFooHandleFacade(). You probably know what a "Handle" is
in Jazz terminology (see IItemHandle javadoc for more), but you may not
have seen the term "Facade" before. Facades are a mechanism we use (and
you can too) for creating API around the storage model types generated
by EMF. For example IContributor is the facade for Contributor and in
general the name IFoo is used for the facade for storage model type Foo.
Ritchie wrote a wiki topic about the M2 codegen changes that also has a
great overview of facades:
https://jazz.net/wiki/bin/view/Main/M2CodegenChanges . I really
recommend reading this for more gory details about the codegen changes
but especially for his overview of facades.


Chris

permanent link
Chris Daly (61651) | answered Aug 22 '07, 4:36 p.m.
JAZZ DEVELOPER
Igor Foox wrote:
...
Chris, please correct me if I'm getting any of this wrong.


This is basically right but I'll add a few details to clarify.

First, to encounter the problem Igor is describing you would have to go
beyond the JazzTalk walkthrough. Specifically you would have to add an
EReference in your model that refers to a type in another storage model
(for instance it looks like Igor made an EReference to the Contributor
type in the repository model).

What really happened to cause this is complicated, but it boils down to
us moving from EMF 2.3.0M7 to EMF 2.3.0(final) for the Jazz M2 release.
The old codegen doesn't work with the final 2.3.0 EMF, but the new
codegen has slightly different generation patterns. The components that
ship with Jazz (repository, build, workitem, etc...) have regenerated
their models, but this was done after M2. So any post-M2 weekly build
should include the missing methods, but I don't see a post-M2 weekly
build on jazz.net yet.

I wasn't sure how fast people would pick up on JazzTalk and start trying
to go beyond it by developing their own storage models, but it's
happening more quickly than I expected. :-) I'm curious to know how
many people out there are building storage models. It would help me to
plan what I can do to best help you. So if you want to be counted in my
"storage model developer census", please reply to this thread and
mention that you are developing a storage model.

One more thing: As Igor pointed out, the methods that don't resolve have
names like getFooHandleFacade(). You probably know what a "Handle" is
in Jazz terminology (see IItemHandle javadoc for more), but you may not
have seen the term "Facade" before. Facades are a mechanism we use (and
you can too) for creating API around the storage model types generated
by EMF. For example IContributor is the facade for Contributor and in
general the name IFoo is used for the facade for storage model type Foo.
Ritchie wrote a wiki topic about the M2 codegen changes that also has
a great overview of facades:
https://jazz.net/wiki/bin/view/Main/M2CodegenChanges . I really
recommend reading this for more gory details about the codegen changes
but especially for his overview of facades.


Chris

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.