| Re: Existing genmodel not picked up [message #477986] |
Wed, 19 November 2008 13:51  |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Volker,
Comments below.
Volker Stolz wrote:
> Dear all,
> I defined a UML profile, and generated code through ecore and a genmodel
> description.
>
> In plugin.xml, I have
> <package
> class="RCOSPrimitiveTypesPackageImpl"
How can the class have no package qualification?
>
> 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.
>
I don't know much about profiles.
> 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!
>
Did the plugin with the above registration successfully install in the
runtime environment?
> 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?
>
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..
> Volker
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
| Re: Existing genmodel not picked up [message #477993 is a reply to message #477991] |
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 -
|
|
|
|
| Re: Existing genmodel not picked up [message #627210 is a reply to message #477991] |
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.02199 seconds
] 
Search
Help
Register
Login
Home
