[news.eclipse.modeling.gmt] Re: [Epsilon] Problems using HUTN with UML m

[Louis Rose <louis@xxxxxxxxxxxxx>]

Hi Pau,

I'm glad that the first fix worked. Many thanks for this bug report.

This time, the problem was caused by us neglecting to inspect the nsUri 
specified in the Spec section in the final model generator phase. This 
has now been fixed.

CVS migration activities are still occuring for Epsilon, so I'm afraid 
we have to ask you to overlay your HUTN engine JAR file once again. 
Please find attached a new fix.

Both this fix and the previous one, will appear in the next release of 
HUTN, which we will produce subsequent to the completion of the CVS 
migration activities.

I thought it best to mention that I'll be on vacation for the next 
couple of weeks, and I won't be checking the newsgroup for the next 10 
days. Should you have any further problems, I'll be in contact as soon 
as I return.

Many thanks,
Louis.

Pau Giner wrote:
> Hello,
>
> I applied the patch and now UML models can be generated (I tried the 
> example I commented in the previous mail). However, I discovered another 
> problem, a kind of name collision:
>
> The UML example I use works depending wether another metamode (namely X) 
> is registered.
>
> The key point is that in metamodel X I have defined metaclases named 
> "Class" and "Package". So when metamodel X is registered this metaclases 
> are the ones HUTN is trying to use despite I indicate in the @Spec of 
> the example that I'm using the UML metamodel.
>
>
> So, before registering X, the model is generated, but after it I get 
> this error:
>
> org.epsilon.hutn.exceptions.HutnGenerationException: Property 
> 'ownedType' not found in object 
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl@356eb0 [eClass: 
> org.eclipse.emf.ecore.impl.EClassImpl@18380a4 [name: Package] 
> [instanceClassName: null] [abstract: false, interface: false]] (152:4)
>
>
> Restricting the used classes to the indicated namespace can be a 
> solution. However, considering that there are metamodels that import (or 
> extend) elements from different metamodels, the solution maybe is not so 
> easy.
>
> In any case the problem now seems that it is not UML-specific, but 
> related to the way HUTN looks for metaclasses.
>
>
>
> --Pau Giner
>
>
> Louis Rose escribió:
> > Hi Pau,
> >
> > As you anticipated, the problem was caused by UML2 using different 
> > datatypes to Ecore. We've fixed the issue by validating against the 
> > underlying Java datatype, rather than the Ecore datatype.
> >
> > We're currently undergoing migration activities with Epsilon, so we're 
> > not interacting with the CVS server. So I've attached a fix to this 
> > message. To apply the fix, you'll need to:
> >
> > 1) Close Eclipse
> >
> > 2) Locate the HUTN engine plugin JAR in your Eclipse installation. 
> > Usually called: <<eclipse 
> > location>>/plugins/org.epsilon.hutn.engine_1.0.1.jar
> >
> > 3) Unzip the HUTN engine plugin JAR, and overlay the binary code 
> > directory with the archive file attached to this message.
> >
> > 4) Create a new JAR file from the overlay, and replace the 
> > org.epsilon.hutn.engine_1.0.1.jar
> >
> > 5) Restart Eclipse
> >
> > Let us know if this fixes the problem, if you need any clarification 
> > on how to overlay the attachment.
> >
> > If you could also open a bug report on the GMT buzilla website 
> > (http://dev.eclipse.org/bugs/buglist.cgi?product=gmt&cmdtype=doit&order=Reuse+same+sort+as+last+time), 
> > we'll then patch Epsilon once our CVS migration has been completed. 
> > Thanks!
> >
> > Many thanks,
> > Louis.
> >
> >
> >
> > Pau Giner wrote:
> > > Hello,
> > > I've experienced problems with HUTN when trying to define a UML 
> > > model. The problem I guess is that UML metamodel uses its own 
> > > dataTypes. So HUTN cannot convert strings to the UML-defined String 
> > > datatype.
> > >
> > >
> > > For example, if I define the following:
> > >
> > > @Spec {
> > >   MetaModel "uml" {
> > >     nsUri = "http://www.eclipse.org/uml2/2.1.0/UML";
> > >   }
> > > }
> > >
> > > Packages {
> > >   Package "Pk" {
> > >     name: "package"
> > >     nestedPackage: Profile "Pr" { name: "profile" }
> > >     ownedType: Class "C" { name: "class" }
> > >   }
> > > }
> > >
> > >
> > >
> > > I get the following error:
> > >
> > > [Line: 9, Column: 5, Reason: Expected String for: name, Line: 10, 
> > > Column: 35, Reason: Expected String for: name, Line: 11, Column: 28, 
> > > Reason: Expected String for: name]
> > >
> > > Is there any construct to handle the creation of these datatypes?
> > >
> > > --Pau

Attachment: name-clash-fix.zip
Description: Zip archive