|
|
|
Re: Existing genmodel not picked up [message #425225 is a reply to message #425212] |
Thu, 20 November 2008 06:30 |
Volker Stolz Messages: 63 Registered: July 2009 |
Member |
|
|
In article <gg1doa$v5b$1@build.eclipse.org>,
"James Bruck" <jbruck@ca.ibm.com> wrote:
> "Ed Merks" <Ed.Merks@gmail.com> wrote in message
> news:gg15kk$jbf$1@build.eclipse.org...
> > Volker,
> >
> > Comments below.
> >
> > Volker Stolz wrote:
> >> Dear all,
> >> I defined a UML profile, and generated code through ecore and a genmodel
> >> description.
>
> One doesn't typically generate code from a profile unless you intend on
> using static profile definition. Please ensure that this is what you
> intended.
> Otherwise consider "defining" your profile.
>
>
> >>
> >> In plugin.xml, I have
> >> <package
> >> class="RCOSPrimitiveTypesPackageImpl"
> > How can the class have no package qualification?
>
> That doesn't look right ... how was this created?
That was me cutting the qualification to shorten the line in this
article, sorry.
> >> I'm glad for any suggestion on how to make EMF pick up the existing
> >> files. I'm guessing there must be a way of specifying in the plugin which
> >> ecore belongs to which UML file?
> >>
> > I don't understand where http:///RCOSPrimitiveTypes.ecore would come from.
> > This sounds more like a UML2 question I've added their newsgroup to the
> > "to" list of the reply..
>
> Perhaps attaching the files in question would help in getting to the bottom
> of this.
> A systematic way of reproducing the problem would also be helpful.
Ed, James, thanks for your answers. It turned out that I didn't have the
Ecore::ePackage stereotype applied and thus couldn't pin down the nsURI.
Now I set it to http://rcos.iist.unu.edu/RCOSPrimitiveTypes.library.uml,
and it is preserved when generating the .ecore (I need the ecore to map
some of our primitive types to Java types). I also put this URI in the
generated_package-entry of plugin.xml and it is now picked up properly
in the 2nd Eclipse instance and everything works as expected.
James, as for the reason why we don't use a dynamic profile: we had some
trouble with duplicate Ecore annotations when you update the profile and
re-define it that went away when we switched to the generated
profile-code (and the references of stereotyped elements to the profile
would break). That's probably our fault for not using dynamic profiles
properly that I'll look into next now that this obstacle is sorted out.
Volker
--
United Nations University -
|
|
|
Powered by
FUDForum. Page generated in 0.04903 seconds