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  |
Eclipse User |
|
|
|
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  |
 Frédéric Jouault
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 |
| Eclipse User |
|
|
|
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 #57304 is a reply to message #57278] |
Fri, 10 August 2007 09:32 |
| Eclipse User |
|
|
|
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 |
Frédéric Jouault
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 |
| Eclipse User |
|
|
|
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 |
Frédéric Jouault
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
|
|
|
Goto Forum:
Current Time: Sat Nov 02 21:11:34 GMT 2024
Powered by FUDForum. Page generated in 0.03902 seconds |
] 
Search
Help
Register
Login
Home
