Eclipse Community Forums: GMT (Generative Modeling Technologies) » [MOFScript] Multiple nsURIs in metamodel breaks things?

Help

Home

Home » Archived » GMT (Generative Modeling Technologies) » [MOFScript] Multiple nsURIs in metamodel breaks things?

Show: Today's Messages :: Show Polls :: Message Navigator

[MOFScript] Multiple nsURIs in metamodel breaks things? [message #378848]

Mon, 13 August 2007 17:41

Eclipse User

Originally posted by: matt.mcgill.gmail.com

Hello all,

I've been looking at MOFScript for only about an hour now, so pardon me
if I'm missing something obvious.

I'm hoping to write a MOFScript spec to generate some code from a UML
1.4 model created in ArgoUML. ArgoUML (as I'm sure you know) serializes
its models to XMI by way of MDR. Happily, I found that the Acceleo
Eclipse plugin has provided an Ecore implementation of UML 1.4 and a
converter to take MDR-based UML 1.4 to EMF-based UML 1.4 models.

Unfortunately, I ran into trouble straight-away when trying to generate
code from a converted model using MOFScript. When I try to compile the
following MOFScript:

texttransformation ExampleTransformation (in
uml:"http://www.obeo.fr/acceleo/uml14") {

uml.Class::main () {
'testing...'
}
}

I receive the following output from the compiler:
## Compiling 'broken2.m2t' (Using repository path:
plugins/org.sintef.mofscript.editor_1.2.4/repository\metamod els)
## Parsing 'broken2.m2t'
## Finished Compiling.
## No errors
Error: MTTParseError: Undefined type for metamodel ( uml ): Class, line:
0, column: 0

This is despite having Class show up via code completion. Here's a
second transformation that might help shine further light:

texttransformation ExampleTransformation (in
uml:"http://www.obeo.fr/acceleo/uml14") {

uml.Model::main() {
self.ownedElement->forEach(c:uml.ModelElement) {
'model element: ' c.name
newline(1)
}
self.ownedElement->forEach(c) {
'untyped'
newline(1)
}
}

}

This compiles without error, and produces the following output when
executed on a trivial input model with one Class and three DataTypes
nested directly under the root Model element (no packages, in other words):

untyped
untyped
untyped
untyped

Clearly something is amiss. My best guess is this: in the Ecore version
of the UML 1.4 metamodel supplied by Acceleo, different nsURIs are
supplied for the various subpackages that contain all of the UML
elements. ModelElement, for example, is in the subpackage 'core' with
nsURI "http://www.obeo.fr/acceleo/uml14/core". In fact, the *only* UML
element defined in the Ecore metamodel is Model. For whatever reason,
part of the MOFScript code (the part that handles autocomplete in the
editor, for example) is OK with multiple nsURIs, and part of it (the
important part) is not.

I haven't started code-spelunking yet, but that's the next step. Could
one of the devs/users perhaps provide an explanation and/or simple
work-around, and save me the trouble of digging through the source myself?

Thanks,
-Matt McGill

Report message to a moderator

Re: [MOFScript] Multiple nsURIs in metamodel breaks things? [message #378851 is a reply to message #378848]

Mon, 13 August 2007 17:47

Eclipse User

Originally posted by: matt.mcgill.gmail.com

Hello again,

Just to provide a bit more context, it looks like the exact same problem
is described here about a year ago:

http://dev.eclipse.org/newslists/news.eclipse.technology.gmt /msg00202.html

No work-around is mentioned on that thread, unfortunately.

-Matt McGill

Report message to a moderator

Re: [MOFScript] Multiple nsURIs in metamodel breaks things? [message #378854 is a reply to message #378848]

Mon, 13 August 2007 20:19

Eclipse User

Originally posted by: matt.mcgill.gmail.com

Ok, I decided I was up for the code-spelunking after all, and I am
getting some *really* weird results here. I simple search for the error
I mentioned in the first post brought me to
MofScriptModelChecker.checkRuleContext in the parser plugin, and
subsequently to the getMetaModelClassifier method in the same class. It
didn't look broken upon visual inspection, but I commented out the check
in checkRuleContext just to be safe. Sure enough, I no longer received
the error when compiling, and the MOFScript executed as expected.

I thought the fix would be easy... turns out its a ClassLoader problem
of all things(!). For whatever reason, all of the Strings in the
metamodel have org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
as their classloader, while the classifierName param to
getMetaModelClassifier is loaded by the bootstrap classloader (null).
Since the Strings being compared are from different ClassLoaders, the
comparison always fails.

So it's looking like the problem probably isn't with MOFScript at all.
I'm going to go check the plugin code for Acceleo that registers its
metamodels with EMF and see if they've done something screwey. Googling
for 'Eclipse classloader String' turned up a post on the Acceleo forums
as the 5th hit... not a good sign.

I am so sick of ClassLoader issues. Fighting them with Commons
Logging... fighting them with Tomcat... fighting them with every other
application server in the known universe... fighting them with Ant...
fighting them with Eclipse... fighting them with Maven... it never
ends![/rant]

I will report my findings. In the meantime, any input would be
appreciated. I fall into the beginner/intermediate category of Eclipse
plugin development, so I might miss something that some of you gurus out
there wouldn't.

-Matt McGill

Matt McGill wrote:
> Hello all,
>
> I've been looking at MOFScript for only about an hour now, so pardon me
> if I'm missing something obvious.
>
> I'm hoping to write a MOFScript spec to generate some code from a UML
> 1.4 model created in ArgoUML. ArgoUML (as I'm sure you know) serializes
> its models to XMI by way of MDR. Happily, I found that the Acceleo
> Eclipse plugin has provided an Ecore implementation of UML 1.4 and a
> converter to take MDR-based UML 1.4 to EMF-based UML 1.4 models.
>
> Unfortunately, I ran into trouble straight-away when trying to generate
> code from a converted model using MOFScript. When I try to compile the
> following MOFScript:
>
> texttransformation ExampleTransformation (in
> uml:"http://www.obeo.fr/acceleo/uml14") {
>
> uml.Class::main () {
> 'testing...'
> }
> }
>
> I receive the following output from the compiler:
> ## Compiling 'broken2.m2t' (Using repository path:
> plugins/org.sintef.mofscript.editor_1.2.4/repository\metamod els)
> ## Parsing 'broken2.m2t'
> ## Finished Compiling.
> ## No errors
> Error: MTTParseError: Undefined type for metamodel ( uml ): Class, line:
> 0, column: 0
>
> This is despite having Class show up via code completion. Here's a
> second transformation that might help shine further light:
>
> texttransformation ExampleTransformation (in
> uml:"http://www.obeo.fr/acceleo/uml14") {
>
> uml.Model::main() {
> self.ownedElement->forEach(c:uml.ModelElement) {
> 'model element: ' c.name
> newline(1)
> }
> self.ownedElement->forEach(c) {
> 'untyped'
> newline(1)
> }
> }
>
> }
>
> This compiles without error, and produces the following output when
> executed on a trivial input model with one Class and three DataTypes
> nested directly under the root Model element (no packages, in other words):
>
> untyped
> untyped
> untyped
> untyped
>
> Clearly something is amiss. My best guess is this: in the Ecore version
> of the UML 1.4 metamodel supplied by Acceleo, different nsURIs are
> supplied for the various subpackages that contain all of the UML
> elements. ModelElement, for example, is in the subpackage 'core' with
> nsURI "http://www.obeo.fr/acceleo/uml14/core". In fact, the *only* UML
> element defined in the Ecore metamodel is Model. For whatever reason,
> part of the MOFScript code (the part that handles autocomplete in the
> editor, for example) is OK with multiple nsURIs, and part of it (the
> important part) is not.
>
> I haven't started code-spelunking yet, but that's the next step. Could
> one of the devs/users perhaps provide an explanation and/or simple
> work-around, and save me the trouble of digging through the source myself?
>
> Thanks,
> -Matt McGill

Report message to a moderator

Re: [MOFScript] Multiple nsURIs in metamodel breaks things? [message #378859 is a reply to message #378854]

Mon, 13 August 2007 21:20

Eclipse User

Originally posted by: matt.mcgill.gmail.com

Well, I'm completely stumped. Though I don't remember changing anything,
all Strings' Classes' ClassLoaders are now null, and things still
inexplicably don't work. If I iterate through all the Classifiers in
each package, classifier.getName().equals("Class") always returns false
even though the printlns clearly show that the Class classifier is being
returned.

Commenting out the misbehaving portiong of checkRuleContext gets rid of
the compile error, but MOFScripts still do not execute correctly. If I
write an entry point rule on uml.Class, it fires correctly. If, on the
other hand, I write an entry point rule for uml.Model and in that rule
have self.ownedElement->forEach(c:uml.Class) {...} the loop is never
entered.

I still think it's classloader problems, but I don't know which piece of
software is to blame, and I can't even pinpoint the problem. Whether
it's a problem with MOFScript or not, this is a showstopper for me. Help
would be appreciated!

-Matt McGill

Matt McGill wrote:
> Ok, I decided I was up for the code-spelunking after all, and I am
> getting some *really* weird results here. I simple search for the error
> I mentioned in the first post brought me to
> MofScriptModelChecker.checkRuleContext in the parser plugin, and
> subsequently to the getMetaModelClassifier method in the same class. It
> didn't look broken upon visual inspection, but I commented out the check
> in checkRuleContext just to be safe. Sure enough, I no longer received
> the error when compiling, and the MOFScript executed as expected.
>
> I thought the fix would be easy... turns out its a ClassLoader problem
> of all things(!). For whatever reason, all of the Strings in the
> metamodel have org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader
> as their classloader, while the classifierName param to
> getMetaModelClassifier is loaded by the bootstrap classloader (null).
> Since the Strings being compared are from different ClassLoaders, the
> comparison always fails.
>
> So it's looking like the problem probably isn't with MOFScript at all.
> I'm going to go check the plugin code for Acceleo that registers its
> metamodels with EMF and see if they've done something screwey. Googling
> for 'Eclipse classloader String' turned up a post on the Acceleo forums
> as the 5th hit... not a good sign.
>
> I am so sick of ClassLoader issues. Fighting them with Commons
> Logging... fighting them with Tomcat... fighting them with every other
> application server in the known universe... fighting them with Ant...
> fighting them with Eclipse... fighting them with Maven... it never
> ends![/rant]
>
> I will report my findings. In the meantime, any input would be
> appreciated. I fall into the beginner/intermediate category of Eclipse
> plugin development, so I might miss something that some of you gurus out
> there wouldn't.
>
> -Matt McGill
>
> Matt McGill wrote:
>> Hello all,
>>
>> I've been looking at MOFScript for only about an hour now, so pardon
>> me if I'm missing something obvious.
>>
>> I'm hoping to write a MOFScript spec to generate some code from a UML
>> 1.4 model created in ArgoUML. ArgoUML (as I'm sure you know)
>> serializes its models to XMI by way of MDR. Happily, I found that the
>> Acceleo Eclipse plugin has provided an Ecore implementation of UML 1.4
>> and a converter to take MDR-based UML 1.4 to EMF-based UML 1.4 models.
>>
>> Unfortunately, I ran into trouble straight-away when trying to
>> generate code from a converted model using MOFScript. When I try to
>> compile the following MOFScript:
>>
>> texttransformation ExampleTransformation (in
>> uml:"http://www.obeo.fr/acceleo/uml14") {
>>
>> uml.Class::main () {
>> 'testing...'
>> }
>> }
>>
>> I receive the following output from the compiler:
>> ## Compiling 'broken2.m2t' (Using repository path:
>> plugins/org.sintef.mofscript.editor_1.2.4/repository\metamod els)
>> ## Parsing 'broken2.m2t'
>> ## Finished Compiling.
>> ## No errors
>> Error: MTTParseError: Undefined type for metamodel ( uml ): Class,
>> line: 0, column: 0
>>
>> This is despite having Class show up via code completion. Here's a
>> second transformation that might help shine further light:
>>
>> texttransformation ExampleTransformation (in
>> uml:"http://www.obeo.fr/acceleo/uml14") {
>>
>> uml.Model::main() {
>> self.ownedElement->forEach(c:uml.ModelElement) {
>> 'model element: ' c.name
>> newline(1)
>> }
>> self.ownedElement->forEach(c) {
>> 'untyped'
>> newline(1)
>> }
>> }
>>
>> }
>>
>> This compiles without error, and produces the following output when
>> executed on a trivial input model with one Class and three DataTypes
>> nested directly under the root Model element (no packages, in other
>> words):
>>
>> untyped
>> untyped
>> untyped
>> untyped
>>
>> Clearly something is amiss. My best guess is this: in the Ecore
>> version of the UML 1.4 metamodel supplied by Acceleo, different nsURIs
>> are supplied for the various subpackages that contain all of the UML
>> elements. ModelElement, for example, is in the subpackage 'core' with
>> nsURI "http://www.obeo.fr/acceleo/uml14/core". In fact, the *only* UML
>> element defined in the Ecore metamodel is Model. For whatever reason,
>> part of the MOFScript code (the part that handles autocomplete in the
>> editor, for example) is OK with multiple nsURIs, and part of it (the
>> important part) is not.
>>
>> I haven't started code-spelunking yet, but that's the next step. Could
>> one of the devs/users perhaps provide an explanation and/or simple
>> work-around, and save me the trouble of digging through the source
>> myself?
>>
>> Thanks,
>> -Matt McGill

Report message to a moderator