| Existing genmodel not picked up [message #425201] |
Wed, 19 November 2008 07:51  |
Eclipse User |
|
|
|
Dear all,
I defined a UML profile, and generated code through ecore and a genmodel
description.
In plugin.xml, I have
<package
class="RCOSPrimitiveTypesPackageImpl"
genModel="libraries/RCOSPrimitiveTypes.library.genmodel"
uri="http://rcos.iist.unu.edu/RCOSPrimitiveTypes.ecore">
</package>
The URI is the same as in the .ecore-file. The corresponding UML file is
also exported. In the second Eclipse instance that uses this plugin, I
create a UML model that references the UML profile and I use one of the
defined datatypes as an attribute in a class.
When then I want to generate an EMF model from the UML file, the wizard
wants to create RCOSPrimitiveTypes.ecore in the current directory and
doesn't even offer me to select the one with the .genmodel defined
through the plugin!
After a day of struggling, I found that the wizard is actually looking
for a generated_package with URI http:///RCOSPrimitiveTypes.ecore (note
the missing host-part). The
UML->Ecore step produces an ecore file that doesn't reference the
existing package, but rather wants to produce a copy.
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?
Volker
--
United Nations University -
|
|
|
|
|
| Re: Existing genmodel not picked up [message #425225 is a reply to message #425212] |
Thu, 20 November 2008 01:30  |
| Eclipse User |
|
|
|
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.05094 seconds
Home