Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » M2M (model-to-model transformation) » [ATL] EMF named references supported ?
[ATL] EMF named references supported ? [message #57048] Thu, 09 August 2007 15:43 Go to next message
Eclipse UserFriend
Originally posted by: r.c.ladan.tue.nl

Hi,

by default EMF creates references by location, i.e. something like
"ref=//@structuralElements.2/@ae.0"

To support another application, I had to switch to instruct EMF to use
named references, i.e. "ref=n". Here, n is the value of an attribute of
the referenced class, "n" has the option ID set to "true". So you get
something like (n=14):

<structuralElements xsi:type="meta:Package" id="13" name="" ingoing="14"/>
<structuralElements xsi:type="meta:StructuralDependency" id="14"
src="10" dst="13"/>

The closest km3 definition would be:

reference ingoing[*] : StructuralDependency [oppositeOf ...]
...
attribute id unique : String; -- manually set option ID in generated
Ecore file to "true"
...

This works fine for the model editor generated by EMF, but not for ATL.
When I feed this to the ATL (CVS 2007-08-08) engine, it bails out with:

SEVERE: Unresolved reference '14'. (IN, 15, 69)
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Unresolved
reference '14'. (IN, 15, 69)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:81)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
at
org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModel.loadASMEMFMo del(ASMEMFModel.java:332)
at
org.eclipse.m2m.atl.engine.AtlEMFModelHandler.loadModel(AtlE MFModelHandler.java:209)
at meta.presentation.MetaEditor.addInputModel(MetaEditor.java:2 84)
at meta.presentation.MetaEditor.doATLTransformation(MetaEditor. java:342)
at meta.presentation.MetaEditor.transform(MetaEditor.java:829)
at meta.presentation.MetaEditor.run(MetaEditor.java:857)
at org.eclipse.ui.internal.PluginAction.runWithEvent(PluginActi on.java:256)
at
org.eclipse.jface.action.ActionContributionItem.handleWidget Selection(ActionContributionItem.java:545)
at
org.eclipse.jface.action.ActionContributionItem.access$2(Act ionContributionItem.java:490)
at
org.eclipse.jface.action.ActionContributionItem$5.handleEven t(ActionContributionItem.java:402)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java :66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:938)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.ja va:3682)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :3293)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:2389)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2353)
at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:22 19)
at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:466)
at
org.eclipse.core.databinding.observable.Realm.runWithDefault (Realm.java:289)
at
org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Work bench.java:461)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.j ava:149)
at
org.eclipse.ui.internal.ide.application.IDEApplication.start (IDEApplication.java:106)
at
org.eclipse.equinox.internal.app.EclipseAppHandle.run(Eclips eAppHandle.java:153)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .runApplication(EclipseAppLauncher.java:106)
at
org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher .start(EclipseAppLauncher.java:76)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:363)
at
org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseS tarter.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java: 504)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:443)
at org.eclipse.equinox.launcher.Main.run(Main.java:1169)
at org.eclipse.equinox.launcher.Main.main(Main.java:1144)
Caused by: org.eclipse.emf.ecore.xmi.UnresolvedReferenceException:
Unresolved reference '14'. (IN, 15, 69)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.handleForwardRefer ences(XMLHandler.java:1092)
at
org.eclipse.emf.ecore.xmi.impl.XMLHandler.endDocument(XMLHan dler.java:1168)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .endDocument(Unknown
Source)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentS cannerImpl.scanDocument(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuratio n.parse(Unknown
Source)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(U nknown
Source)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser .parse(Unknown
Source)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSA XParser.parse(Unknown
Source)
at javax.xml.parsers.SAXParser.parse(Unknown Source)
at org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:179)
... 37 more
Re: [ATL] EMF named references supported ? [message #57128 is a reply to message #57048] Thu, 09 August 2007 15:58 Go to previous messageGo to next message
Frédéric Jouault is currently offline Frédéric JouaultFriend
Messages: 572
Registered: July 2009
Senior Member
Hello,

> by default EMF creates references by location, i.e. something like
> "ref=//@structuralElements.2/@ae.0"
>
> To support another application, I had to switch to instruct EMF to use
> named references, i.e. "ref=n". Here, n is the value of an attribute of
> the referenced class, "n" has the option ID set to "true". So you get
> something like (n=14):
>
> <structuralElements xsi:type="meta:Package" id="13" name=""
> ingoing="14"/>
> <structuralElements xsi:type="meta:StructuralDependency" id="14"
> src="10" dst="13"/>
>
> The closest km3 definition would be:
>
> reference ingoing[*] : StructuralDependency [oppositeOf ...]
> ...
> attribute id unique : String; -- manually set option ID in generated
> Ecore file to "true"

In KM3 and in Ecore, unique only means something for multivalued
attributes. It specifies that a given value may appear only once.

However, it is possible to implement an annotation mechanism similar to
what we currently use for nsURI and nsPrefix.

In the mean time, you can of course set the ID option manually as you
suggest.


> This works fine for the model editor generated by EMF, but not for ATL.
> When I feed this to the ATL (CVS 2007-08-08) engine, it bails out with:

Because ATL uses EMF to load metamodels and models, this should work.

However, EMF may require a specific option to be set (or unset). You may
try to tweak with the options passed to get it to work.

Could you please open a bugzilla entry to follow the progress on this issue?
Thanks.


Regards,

Frédéric Jouault
Re: [ATL] EMF named references supported ? [message #57229 is a reply to message #57128] Fri, 10 August 2007 07:20 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: r.c.ladan.tue.nl

Frédéric Jouault wrote:
> Hello,
>
> > by default EMF creates references by location, i.e. something like
> > "ref=//@structuralElements.2/@ae.0"
> >
> > To support another application, I had to switch to instruct EMF to use
> > named references, i.e. "ref=n". Here, n is the value of an attribute of
> > the referenced class, "n" has the option ID set to "true". So you get
> > something like (n=14):
> >
> > <structuralElements xsi:type="meta:Package" id="13" name=""
> > ingoing="14"/>
> > <structuralElements xsi:type="meta:StructuralDependency" id="14"
> > src="10" dst="13"/>
> >
> > The closest km3 definition would be:
> >
> > reference ingoing[*] : StructuralDependency [oppositeOf ...]
> > ...
> > attribute id unique : String; -- manually set option ID in generated
> > Ecore file to "true"
>
> In KM3 and in Ecore, unique only means something for multivalued
> attributes. It specifies that a given value may appear only once.
>
Ah, I interpreted it that a certain attribute must have unique values
(for that attribute) in the entire model. Since this isn't true, the
EMF ID option wasn't set in the generated ecore model.

> However, it is possible to implement an annotation mechanism similar to
> what we currently use for nsURI and nsPrefix.

Something like --@ID after the attribute declaration?

>
> In the mean time, you can of course set the ID option manually as you
> suggest.
>
> > This works fine for the model editor generated by EMF, but not for ATL.
> > When I feed this to the ATL (CVS 2007-08-08) engine, it bails out with:
>
> Because ATL uses EMF to load metamodels and models, this should work.
>
It works fine after explicitly setting the ID option in the generated
EMF model.
> However, EMF may require a specific option to be set (or unset). You may
> try to tweak with the options passed to get it to work.
>
> Could you please open a bugzilla entry to follow the progress on this
> issue?

Not needed.

Regards,
Rene
Re: [ATL] EMF named references supported ? [message #57278 is a reply to message #57229] Fri, 10 August 2007 08:37 Go to previous messageGo to next message
Frédéric Jouault is currently offline Frédéric JouaultFriend
Messages: 572
Registered: July 2009
Senior Member
Hi Rene,

>> In KM3 and in Ecore, unique only means something for multivalued
>> attributes. It specifies that a given value may appear only once.
>>
> Ah, I interpreted it that a certain attribute must have unique values
> (for that attribute) in the entire model. Since this isn't true, the
> EMF ID option wasn't set in the generated ecore model.

Ok. In fact, the "unique" keyword in KM3 is equivalent to the "unique"
attribute of ETypedFeature.


>> However, it is possible to implement an annotation mechanism similar
>> to what we currently use for nsURI and nsPrefix.
>
> Something like --@ID after the attribute declaration?

Yes. Note that the next version of KM3 will have a better solution for
such annotations than using comments.


> It works fine after explicitly setting the ID option in the generated
> EMF model.

Ok, that's interesting to know.

Could you please add a FAQ entry (in http://wiki.eclipse.org/ATL_FAQ) to
make this interesting information public knowledge? ;-)

Thanks.


Best regards,

Frédéric Jouault
Re: [ATL] EMF named references supported ? [message #57304 is a reply to message #57278] Fri, 10 August 2007 09:32 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: r.c.ladan.tue.nl

Frédéric Jouault wrote:
> Hi Rene,
>
> >> In KM3 and in Ecore, unique only means something for multivalued
> >> attributes. It specifies that a given value may appear only once.
> >>
> > Ah, I interpreted it that a certain attribute must have unique values
> > (for that attribute) in the entire model. Since this isn't true, the
> > EMF ID option wasn't set in the generated ecore model.
>
> Ok. In fact, the "unique" keyword in KM3 is equivalent to the "unique"
> attribute of ETypedFeature.
>
>
> >> However, it is possible to implement an annotation mechanism similar
> >> to what we currently use for nsURI and nsPrefix.
> >
> > Something like --@ID after the attribute declaration?
>
> Yes. Note that the next version of KM3 will have a better solution for
> such annotations than using comments.

This doesn't seem to work here (EMF 2.3.0.v20070626, ATL 2.0.0rc2, KM3
v? ). Both

attribute id unique : String; --@iD
and
attribute id unique : String; --@ID

leave the EMF ID attribute false.

> > It works fine after explicitly setting the ID option in the generated
> > EMF model.
>
> Ok, that's interesting to know.
>
> Could you please add a FAQ entry (in http://wiki.eclipse.org/ATL_FAQ) to
> make this interesting information public knowledge? ;-)
>
I'll try :)

> Thanks.
>
>
> Best regards,
>
> Frédéric Jouault
>
Re: [ATL] EMF named references supported ? [message #57377 is a reply to message #57304] Fri, 10 August 2007 10:07 Go to previous messageGo to next message
Frédéric Jouault is currently offline Frédéric JouaultFriend
Messages: 572
Registered: July 2009
Senior Member
Hi Rene,

>> > Something like --@ID after the attribute declaration?
>>
>> Yes. Note that the next version of KM3 will have a better solution for
>> such annotations than using comments.
>
> This doesn't seem to work here (EMF 2.3.0.v20070626, ATL 2.0.0rc2, KM3
> v? ). Both
>
> attribute id unique : String; --@iD
> and
> attribute id unique : String; --@ID
>
> leave the EMF ID attribute false.

Sorry, I meant that this could be implemented, not that it is already
implemented.

The place to implement this is the following transformation:
http://www.eclipse.org/m2m/atl/atlTransformations/#KM32EMF

To follow the way the nsPrefix and nsUri annotations work, I would put
it before:

-- @ID
attribute id : String;

(note that I also removed "unique", which is not necessary because the
attribute is not multivalued).



>> Could you please add a FAQ entry (in http://wiki.eclipse.org/ATL_FAQ)
>> to make this interesting information public knowledge? ;-)
>>
> I'll try :)

Ok, thanks ;-).


Best regards,

Frédéric Jouault
Re: [ATL] EMF named references supported ? [message #57433 is a reply to message #57304] Fri, 10 August 2007 10:52 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: r.c.ladan.tue.nl

Rene Ladan wrote:
> Frédéric Jouault wrote:
>> Hi Rene,
>>
>> >> In KM3 and in Ecore, unique only means something for multivalued
>> >> attributes. It specifies that a given value may appear only once.
>> >>
>> > Ah, I interpreted it that a certain attribute must have unique values
>> > (for that attribute) in the entire model. Since this isn't true, the
>> > EMF ID option wasn't set in the generated ecore model.
>>
>> Ok. In fact, the "unique" keyword in KM3 is equivalent to the "unique"
>> attribute of ETypedFeature.
>>
>>
>> >> However, it is possible to implement an annotation mechanism similar
>> >> to what we currently use for nsURI and nsPrefix.
>> >
>> > Something like --@ID after the attribute declaration?
>>
>> Yes. Note that the next version of KM3 will have a better solution for
>> such annotations than using comments.
>
> This doesn't seem to work here (EMF 2.3.0.v20070626, ATL 2.0.0rc2, KM3
> v? ). Both
>
> attribute id unique : String; --@iD
> and
> attribute id unique : String; --@ID
>
> leave the EMF ID attribute false.
>
>> > It works fine after explicitly setting the ID option in the generated
>> > EMF model.
>>
>> Ok, that's interesting to know.
>>
>> Could you please add a FAQ entry (in http://wiki.eclipse.org/ATL_FAQ)
>> to make this interesting information public knowledge? ;-)
>>
> I'll try :)
>
I've added an initial text to the wiki, feel free to correct/enhance it.

Regards,
Rene
Re: [ATL] EMF named references supported ? [message #57456 is a reply to message #57433] Fri, 10 August 2007 12:10 Go to previous message
Frédéric Jouault is currently offline Frédéric JouaultFriend
Messages: 572
Registered: July 2009
Senior Member
Rene Ladan wrote:
> Rene Ladan wrote:
>> Frédéric Jouault wrote:
>>> Hi Rene,
>>>
>>> >> In KM3 and in Ecore, unique only means something for multivalued
>>> >> attributes. It specifies that a given value may appear only once.
>>> >>
>>> > Ah, I interpreted it that a certain attribute must have unique values
>>> > (for that attribute) in the entire model. Since this isn't true, the
>>> > EMF ID option wasn't set in the generated ecore model.
>>>
>>> Ok. In fact, the "unique" keyword in KM3 is equivalent to the
>>> "unique" attribute of ETypedFeature.
>>>
>>>
>>> >> However, it is possible to implement an annotation mechanism similar
>>> >> to what we currently use for nsURI and nsPrefix.
>>> >
>>> > Something like --@ID after the attribute declaration?
>>>
>>> Yes. Note that the next version of KM3 will have a better solution
>>> for such annotations than using comments.
>>
>> This doesn't seem to work here (EMF 2.3.0.v20070626, ATL 2.0.0rc2, KM3
>> v? ). Both
>>
>> attribute id unique : String; --@iD
>> and
>> attribute id unique : String; --@ID
>>
>> leave the EMF ID attribute false.
>>
>>> > It works fine after explicitly setting the ID option in the generated
>>> > EMF model.
>>>
>>> Ok, that's interesting to know.
>>>
>>> Could you please add a FAQ entry (in http://wiki.eclipse.org/ATL_FAQ)
>>> to make this interesting information public knowledge? ;-)
>>>
>> I'll try :)
>>
> I've added an initial text to the wiki, feel free to correct/enhance it.


Thanks.


Regards,

Frédéric Jouault
Previous Topic:[ATL] Trying ATL without installing Eclipse
Next Topic:[ATL] uml2 model/profile in transformation
Goto Forum:
  


Current Time: Mon Mar 08 13:37:10 GMT 2021

Powered by FUDForum. Page generated in 0.02347 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top