Home » Archived » M2M (model-to-model transformation) » [M2M] [Fwd: Re: resolving volatile references]
| [M2M] [Fwd: Re: resolving volatile references] [message #61340] |
Mon, 10 September 2007 07:07  |
Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
This is a multi-part message in MIME format.
--------------080305050302000604000005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
I got this answer back from Ed Merks when I reposted the question posed
in "resolving links to input model" on the eclipse.tools.emf newsgroup.
Regards,
Rene
--------------080305050302000604000005
Content-Type: message/rfc822;
name="Re: resolving volatile references.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="Re: resolving volatile references.eml"
Path: build.eclipse.org!not-for-mail
From: Ed Merks <merks@ca.ibm.com>
Newsgroups: eclipse.tools.emf
Subject: Re: resolving volatile references
Date: Fri, 07 Sep 2007 12:38:22 -0400
Organization: EclipseCorner
Message-ID: <fbrumn$tto$1@build.eclipse.org>
References: <fbrk2h$f31$1@build.eclipse.org>
NNTP-Posting-Host: cpe001839b364d5-cm0012c9db3b32.cpe.net.cable.rogers.com
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: build.eclipse.org 1189182999 30648 74.118.84.94 (7 Sep 2007 16:36:39 GMT)
X-Complaints-To: news@build.eclipse.org
NNTP-Posting-Date: Fri, 7 Sep 2007 16:36:39 +0000 (UTC)
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
In-Reply-To: <fbrk2h$f31$1@build.eclipse.org>
Xref: build.eclipse.org eclipse.tools.emf:27027
Rene,
Comments below.
Rene Ladan wrote:
> Hi,
>
> I originally posted a more elaborated version of this question to the
> eclipse.modeling.m2m newsgroup, but got redirected to this group.
>
> The original question was what to do when I have an input model Mi and
> a set
> of transformations:
> * An input model Mi:
> <a F="false" id="1" b_ref="#2">
> <c F="false" id="3"/>
> </a>
> <b F="true" val="10" id="2"/>
>
> Here, and elsewhere, attribute id is an unique attribute which can
> be used
> to reference other elements.
> The type of a is ma, that of b is mb, and that of c is mc.
>
> * transformation copy_a, which copies element a, including its
> children, references
> and attributes whenever a.F is false
> * transformation copy_c, idem for element c
> * transformation transform_b, which copies element b, including its
> children,
> references and attributes and increases the value of b.val, whenever
> b.F is true
>
> The result is that a and c get copied to the output model Mo, leaving the
> original reference to b is unresolved; and that transform_b adds a new
> version of b:
> <a F="false" id="1">
> <b_ref xsi:type="mb" href="platform:/<project>/Mi#2"/>
> <c F="false" id="3"/>
> </a>
> <b F="true" val="11" id="2"/>
>
> What I need is that href to Mi#2 gets replaced by a reference to
> element b of Mo
> (i.e. Mo#2). Since the id attributes are unique, it is "obvious" that
> Mo#2 == transform_b(Mi#2).
>
> The resulting file (with the href) is editable in the standard EMF
> editor, but
> things get a bit tricky when using a temporary buffer for Mi (which is
> what I do
> in my own EMF editor). In that case, there is no Mi to refer to after
> the
> transformation, which means that the hrefs are invalid.
>
> Any ideas on how to do this?
I think you are saying that b_ref will be a broken proxy in the result.
I.e., EObject.eIsProxy will be true since it can't resolve properly. As
such, you can cast to InternalEObject and ask for the eProxyURI of that
instance and from there you can determine from the URI's fragment that
it's trying to refer to ID 2 in resource Mi. You can either replace the
proxy URI, or get the Resource for Mo and call getEObject with the
ID/fragment to find the new object and then replace the unresolved proxy
with that properly resolved replacement.
>
> Regards,
> Rene
--------------080305050302000604000005--
|
|
|
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #61415 is a reply to message #61340] |
Mon, 10 September 2007 08:25  |
| Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Hi Rene,
Thanks for posting Ed's answer here. Did you manage to solve your problem ?
Regards,
Mikael
Rene Ladan wrote:
> Hi,
>
> I got this answer back from Ed Merks when I reposted the question posed
> in "resolving links to input model" on the eclipse.tools.emf newsgroup.
>
> Regards,
> Rene
>
> ------------------------------------------------------------ ------------
>
> Sujet:
> Re: resolving volatile references
> Expéditeur:
> Ed Merks <merks@ca.ibm.com>
> Date:
> Fri, 07 Sep 2007 12:38:22 -0400
>
> Forums de discussion:
> eclipse.tools.emf
>
>
> Rene,
>
> Comments below.
>
>
> Rene Ladan wrote:
>> Hi,
>>
>> I originally posted a more elaborated version of this question to the
>> eclipse.modeling.m2m newsgroup, but got redirected to this group.
>>
>> The original question was what to do when I have an input model Mi and
>> a set
>> of transformations:
>> * An input model Mi:
>> <a F="false" id="1" b_ref="#2">
>> <c F="false" id="3"/>
>> </a>
>> <b F="true" val="10" id="2"/>
>>
>> Here, and elsewhere, attribute id is an unique attribute which can
>> be used
>> to reference other elements.
>> The type of a is ma, that of b is mb, and that of c is mc.
>>
>> * transformation copy_a, which copies element a, including its
>> children, references
>> and attributes whenever a.F is false
>> * transformation copy_c, idem for element c
>> * transformation transform_b, which copies element b, including its
>> children,
>> references and attributes and increases the value of b.val, whenever
>> b.F is true
>>
>> The result is that a and c get copied to the output model Mo, leaving the
>> original reference to b is unresolved; and that transform_b adds a new
>> version of b:
>> <a F="false" id="1">
>> <b_ref xsi:type="mb" href="platform:/<project>/Mi#2"/>
>> <c F="false" id="3"/>
>> </a>
>> <b F="true" val="11" id="2"/>
>>
>> What I need is that href to Mi#2 gets replaced by a reference to
>> element b of Mo
>> (i.e. Mo#2). Since the id attributes are unique, it is "obvious" that
>> Mo#2 == transform_b(Mi#2).
>>
>> The resulting file (with the href) is editable in the standard EMF
>> editor, but
>> things get a bit tricky when using a temporary buffer for Mi (which is
>> what I do
>> in my own EMF editor). In that case, there is no Mi to refer to after
>> the
>> transformation, which means that the hrefs are invalid.
>>
>> Any ideas on how to do this?
> I think you are saying that b_ref will be a broken proxy in the result.
> I.e., EObject.eIsProxy will be true since it can't resolve properly. As
> such, you can cast to InternalEObject and ask for the eProxyURI of that
> instance and from there you can determine from the URI's fragment that
> it's trying to refer to ID 2 in resource Mi. You can either replace the
> proxy URI, or get the Resource for Mo and call getEObject with the
> ID/fragment to find the new object and then replace the unresolved proxy
> with that properly resolved replacement.
>>
>> Regards,
>> Rene
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
| |
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #61532 is a reply to message #61494] |
Mon, 10 September 2007 13:56 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Rene Ladan wrote:
> Mikaël Barbero wrote:
>> Hi Rene,
>>
>> Thanks for posting Ed's answer here. Did you manage to solve your
>> problem ?
>>
> Yes, see the attachment (FTP upload failed...) for an example project in
> which the file test_emf/TestSerialization.java transforms
> test-all-out.ecore
> into resulting.ecore. The meta-model is a slimmed version of the actual
> meta-model.
>
Well, the attachment provides a proof-of-concept solution. I'm currently
updating the real application (lots of "if" checks because of all the
different model elements...). Would it be an idea to integrate the code
in TestSerialization.java in the ATL engine ?
Regards,
Rene
>
>> Regards,
>> Mikael
>>
>> Rene Ladan wrote:
>>> Hi,
>>>
>>> I got this answer back from Ed Merks when I reposted the question posed
>>> in "resolving links to input model" on the eclipse.tools.emf newsgroup.
>>>
>>> Regards,
>>> Rene
>>>
>>> ------------------------------------------------------------ ------------
>>>
>>> Sujet:
>>> Re: resolving volatile references
>>> Expéditeur:
>>> Ed Merks <merks@ca.ibm.com>
>>> Date:
>>> Fri, 07 Sep 2007 12:38:22 -0400
>>>
>>> Forums de discussion:
>>> eclipse.tools.emf
>>>
>>>
>>> Rene,
>>>
>>> Comments below.
>>>
>>>
>>> Rene Ladan wrote:
>>>> Hi,
>>>>
>>>> I originally posted a more elaborated version of this question to the
>>>> eclipse.modeling.m2m newsgroup, but got redirected to this group.
>>>>
>>>> The original question was what to do when I have an input model Mi
>>>> and a set
>>>> of transformations:
>>>> * An input model Mi:
>>>> <a F="false" id="1" b_ref="#2">
>>>> <c F="false" id="3"/>
>>>> </a>
>>>> <b F="true" val="10" id="2"/>
>>>>
>>>> Here, and elsewhere, attribute id is an unique attribute which can
>>>> be used
>>>> to reference other elements.
>>>> The type of a is ma, that of b is mb, and that of c is mc.
>>>>
>>>> * transformation copy_a, which copies element a, including its
>>>> children, references
>>>> and attributes whenever a.F is false
>>>> * transformation copy_c, idem for element c
>>>> * transformation transform_b, which copies element b, including its
>>>> children,
>>>> references and attributes and increases the value of b.val,
>>>> whenever b.F is true
>>>>
>>>> The result is that a and c get copied to the output model Mo,
>>>> leaving the
>>>> original reference to b is unresolved; and that transform_b adds a
>>>> new version of b:
>>>> <a F="false" id="1">
>>>> <b_ref xsi:type="mb" href="platform:/<project>/Mi#2"/>
>>>> <c F="false" id="3"/>
>>>> </a>
>>>> <b F="true" val="11" id="2"/>
>>>>
>>>> What I need is that href to Mi#2 gets replaced by a reference to
>>>> element b of Mo
>>>> (i.e. Mo#2). Since the id attributes are unique, it is "obvious" that
>>>> Mo#2 == transform_b(Mi#2).
>>>>
>>>> The resulting file (with the href) is editable in the standard EMF
>>>> editor, but
>>>> things get a bit tricky when using a temporary buffer for Mi (which
>>>> is what I do
>>>> in my own EMF editor). In that case, there is no Mi to refer to
>>>> after the
>>>> transformation, which means that the hrefs are invalid.
>>>>
>>>> Any ideas on how to do this?
>>> I think you are saying that b_ref will be a broken proxy in the
>>> result. I.e., EObject.eIsProxy will be true since it can't resolve
>>> properly. As such, you can cast to InternalEObject and ask for the
>>> eProxyURI of that instance and from there you can determine from the
>>> URI's fragment that it's trying to refer to ID 2 in resource Mi. You
>>> can either replace the proxy URI, or get the Resource for Mo and call
>>> getEObject with the ID/fragment to find the new object and then
>>> replace the unresolved proxy with that properly resolved replacement.
>>>>
>>>> Regards,
>>>> Rene
>>
>>
>>
>
|
|
|
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #61555 is a reply to message #61532] |
Mon, 10 September 2007 14:25 |
| Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
It would be nice. You can open a bug on the Eclipse's bugzilla and post
a patch for the EMF model handler along with its description.
Best regards,
Mikael
Rene Ladan wrote:
> Rene Ladan wrote:
>> Mikaël Barbero wrote:
>>> Hi Rene,
>>>
>>> Thanks for posting Ed's answer here. Did you manage to solve your
>>> problem ?
>>>
>> Yes, see the attachment (FTP upload failed...) for an example project in
>> which the file test_emf/TestSerialization.java transforms
>> test-all-out.ecore
>> into resulting.ecore. The meta-model is a slimmed version of the
>> actual meta-model.
>>
> Well, the attachment provides a proof-of-concept solution. I'm currently
> updating the real application (lots of "if" checks because of all the
> different model elements...). Would it be an idea to integrate the code
> in TestSerialization.java in the ATL engine ?
>
> Regards,
> Rene
>>
>>> Regards,
>>> Mikael
>>>
>>> Rene Ladan wrote:
>>>> Hi,
>>>>
>>>> I got this answer back from Ed Merks when I reposted the question posed
>>>> in "resolving links to input model" on the eclipse.tools.emf newsgroup.
>>>>
>>>> Regards,
>>>> Rene
>>>>
>>>> ------------------------------------------------------------ ------------
>>>>
>>>>
>>>> Sujet:
>>>> Re: resolving volatile references
>>>> Expéditeur:
>>>> Ed Merks <merks@ca.ibm.com>
>>>> Date:
>>>> Fri, 07 Sep 2007 12:38:22 -0400
>>>>
>>>> Forums de discussion:
>>>> eclipse.tools.emf
>>>>
>>>>
>>>> Rene,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Rene Ladan wrote:
>>>>> Hi,
>>>>>
>>>>> I originally posted a more elaborated version of this question to the
>>>>> eclipse.modeling.m2m newsgroup, but got redirected to this group.
>>>>>
>>>>> The original question was what to do when I have an input model Mi
>>>>> and a set
>>>>> of transformations:
>>>>> * An input model Mi:
>>>>> <a F="false" id="1" b_ref="#2">
>>>>> <c F="false" id="3"/>
>>>>> </a>
>>>>> <b F="true" val="10" id="2"/>
>>>>>
>>>>> Here, and elsewhere, attribute id is an unique attribute which
>>>>> can be used
>>>>> to reference other elements.
>>>>> The type of a is ma, that of b is mb, and that of c is mc.
>>>>>
>>>>> * transformation copy_a, which copies element a, including its
>>>>> children, references
>>>>> and attributes whenever a.F is false
>>>>> * transformation copy_c, idem for element c
>>>>> * transformation transform_b, which copies element b, including its
>>>>> children,
>>>>> references and attributes and increases the value of b.val,
>>>>> whenever b.F is true
>>>>>
>>>>> The result is that a and c get copied to the output model Mo,
>>>>> leaving the
>>>>> original reference to b is unresolved; and that transform_b adds a
>>>>> new version of b:
>>>>> <a F="false" id="1">
>>>>> <b_ref xsi:type="mb" href="platform:/<project>/Mi#2"/>
>>>>> <c F="false" id="3"/>
>>>>> </a>
>>>>> <b F="true" val="11" id="2"/>
>>>>>
>>>>> What I need is that href to Mi#2 gets replaced by a reference to
>>>>> element b of Mo
>>>>> (i.e. Mo#2). Since the id attributes are unique, it is "obvious" that
>>>>> Mo#2 == transform_b(Mi#2).
>>>>>
>>>>> The resulting file (with the href) is editable in the standard EMF
>>>>> editor, but
>>>>> things get a bit tricky when using a temporary buffer for Mi (which
>>>>> is what I do
>>>>> in my own EMF editor). In that case, there is no Mi to refer to
>>>>> after the
>>>>> transformation, which means that the hrefs are invalid.
>>>>>
>>>>> Any ideas on how to do this?
>>>> I think you are saying that b_ref will be a broken proxy in the
>>>> result. I.e., EObject.eIsProxy will be true since it can't resolve
>>>> properly. As such, you can cast to InternalEObject and ask for the
>>>> eProxyURI of that instance and from there you can determine from the
>>>> URI's fragment that it's trying to refer to ID 2 in resource Mi.
>>>> You can either replace the proxy URI, or get the Resource for Mo and
>>>> call getEObject with the ID/fragment to find the new object and then
>>>> replace the unresolved proxy with that properly resolved replacement.
>>>>>
>>>>> Regards,
>>>>> Rene
>>>
>>>
>>>
>>
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #61604 is a reply to message #61555] |
Mon, 10 September 2007 14:46 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Mikaël Barbero wrote:
> It would be nice. You can open a bug on the Eclipse's bugzilla and post
> a patch for the EMF model handler along with its description.
Ok, I think that that is more productive than manually writing m*n of similar
if-clauses (m metamodel elements * n references).
Regards,
Rene
>
> Best regards,
> Mikael
>
> Rene Ladan wrote:
>> Rene Ladan wrote:
>>> Mikaël Barbero wrote:
>>>> Hi Rene,
>>>>
>>>> Thanks for posting Ed's answer here. Did you manage to solve your
>>>> problem ?
>>>>
>>> Yes, see the attachment (FTP upload failed...) for an example project in
>>> which the file test_emf/TestSerialization.java transforms
>>> test-all-out.ecore
>>> into resulting.ecore. The meta-model is a slimmed version of the
>>> actual meta-model.
>>>
>> Well, the attachment provides a proof-of-concept solution. I'm currently
>> updating the real application (lots of "if" checks because of all the
>> different model elements...). Would it be an idea to integrate the code
>> in TestSerialization.java in the ATL engine ?
>>
>> Regards,
>> Rene
>>>
>>>> Regards,
>>>> Mikael
>>>>
>>>> Rene Ladan wrote:
>>>>> Hi,
>>>>>
>>>>> I got this answer back from Ed Merks when I reposted the question
>>>>> posed
>>>>> in "resolving links to input model" on the eclipse.tools.emf
>>>>> newsgroup.
>>>>>
>>>>> Regards,
>>>>> Rene
>>>>>
>>>>> ------------------------------------------------------------ ------------
>>>>>
>>>>>
>>>>> Sujet:
>>>>> Re: resolving volatile references
>>>>> Expéditeur:
>>>>> Ed Merks <merks@ca.ibm.com>
>>>>> Date:
>>>>> Fri, 07 Sep 2007 12:38:22 -0400
>>>>>
>>>>> Forums de discussion:
>>>>> eclipse.tools.emf
>>>>>
>>>>>
>>>>> Rene,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Rene Ladan wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I originally posted a more elaborated version of this question to the
>>>>>> eclipse.modeling.m2m newsgroup, but got redirected to this group.
>>>>>>
>>>>>> The original question was what to do when I have an input model Mi
>>>>>> and a set
>>>>>> of transformations:
>>>>>> * An input model Mi:
>>>>>> <a F="false" id="1" b_ref="#2">
>>>>>> <c F="false" id="3"/>
>>>>>> </a>
>>>>>> <b F="true" val="10" id="2"/>
>>>>>>
>>>>>> Here, and elsewhere, attribute id is an unique attribute which
>>>>>> can be used
>>>>>> to reference other elements.
>>>>>> The type of a is ma, that of b is mb, and that of c is mc.
>>>>>>
>>>>>> * transformation copy_a, which copies element a, including its
>>>>>> children, references
>>>>>> and attributes whenever a.F is false
>>>>>> * transformation copy_c, idem for element c
>>>>>> * transformation transform_b, which copies element b, including
>>>>>> its children,
>>>>>> references and attributes and increases the value of b.val,
>>>>>> whenever b.F is true
>>>>>>
>>>>>> The result is that a and c get copied to the output model Mo,
>>>>>> leaving the
>>>>>> original reference to b is unresolved; and that transform_b adds a
>>>>>> new version of b:
>>>>>> <a F="false" id="1">
>>>>>> <b_ref xsi:type="mb" href="platform:/<project>/Mi#2"/>
>>>>>> <c F="false" id="3"/>
>>>>>> </a>
>>>>>> <b F="true" val="11" id="2"/>
>>>>>>
>>>>>> What I need is that href to Mi#2 gets replaced by a reference to
>>>>>> element b of Mo
>>>>>> (i.e. Mo#2). Since the id attributes are unique, it is "obvious"
>>>>>> that
>>>>>> Mo#2 == transform_b(Mi#2).
>>>>>>
>>>>>> The resulting file (with the href) is editable in the standard EMF
>>>>>> editor, but
>>>>>> things get a bit tricky when using a temporary buffer for Mi
>>>>>> (which is what I do
>>>>>> in my own EMF editor). In that case, there is no Mi to refer to
>>>>>> after the
>>>>>> transformation, which means that the hrefs are invalid.
>>>>>>
>>>>>> Any ideas on how to do this?
>>>>> I think you are saying that b_ref will be a broken proxy in the
>>>>> result. I.e., EObject.eIsProxy will be true since it can't resolve
>>>>> properly. As such, you can cast to InternalEObject and ask for the
>>>>> eProxyURI of that instance and from there you can determine from
>>>>> the URI's fragment that it's trying to refer to ID 2 in resource
>>>>> Mi. You can either replace the proxy URI, or get the Resource for
>>>>> Mo and call getEObject with the ID/fragment to find the new object
>>>>> and then replace the unresolved proxy with that properly resolved
>>>>> replacement.
>>>>>>
>>>>>> Regards,
>>>>>> Rene
>>>>
>>>>
>>>>
>>>
>
>
>
|
|
|
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #61770 is a reply to message #61604] |
Tue, 11 September 2007 12:10 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Rene Ladan wrote:
> Mikaël Barbero wrote:
>> It would be nice. You can open a bug on the Eclipse's bugzilla and
>> post a patch for the EMF model handler along with its description.
>
> Ok, I think that that is more productive than manually writing m*n of
> similar
> if-clauses (m metamodel elements * n references).
>
Looking at the source code, it seems that these methods are candidates
for updating:
* org.eclipse.m2m.atl.engine.AtlEMFModelHandler::saveModel (2x)
* org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModelElement::eObj ectToASM
(says something about using a model as a proxy)
* org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModelElement::isNo tAssignable
(change inter-model update procedure?)
* org.eclipse.m2m.atl.drivers.emf4atl.EMFModelLoader::realSave
Is this list correct?
I think this kind of resolving is only applicable to EMF models which use
named resolution by turning on the EMF ID flag. For models which use "path"
resolution, the position of the element to be substituted might have changed,
which means that the substitution might be invalid.
Comments?
Regards,
Rene
|
|
|
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #61957 is a reply to message #61770] |
Wed, 19 September 2007 08:17 |
| Eclipse User |
|
|
|
Originally posted by: r.c.ladan.tue.nl
Rene Ladan wrote:
> Rene Ladan wrote:
>> Mikaël Barbero wrote:
>>> It would be nice. You can open a bug on the Eclipse's bugzilla and
>>> post a patch for the EMF model handler along with its description.
>>
>> Ok, I think that that is more productive than manually writing m*n of
>> similar
>> if-clauses (m metamodel elements * n references).
>>
> Looking at the source code, it seems that these methods are candidates
> for updating:
>
> * org.eclipse.m2m.atl.engine.AtlEMFModelHandler::saveModel (2x)
> * org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModelElement::eObj ectToASM
> (says something about using a model as a proxy)
> * org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModelElement::isNo tAssignable
> (change inter-model update procedure?)
> * org.eclipse.m2m.atl.drivers.emf4atl.EMFModelLoader::realSave
>
> Is this list correct?
>
Ok, either nobody knows or nobody is interested :(
Regards,
Rene
|
|
|
| Re: [M2M] [Fwd: Re: resolving volatile references] [message #62291 is a reply to message #61957] |
Mon, 24 September 2007 07:44 |
| Eclipse User |
|
|
|
Originally posted by: mikael.barbero.gmail.com
Hi Rene,
First, sorry for the late answer. Your guess seems to be OK. Could you
submit a Bug with your patch ?
Regards,
Mikael
Rene Ladan wrote:
> Rene Ladan wrote:
>> Rene Ladan wrote:
>>> Mikaël Barbero wrote:
>>>> It would be nice. You can open a bug on the Eclipse's bugzilla and
>>>> post a patch for the EMF model handler along with its description.
>>>
>>> Ok, I think that that is more productive than manually writing m*n of
>>> similar
>>> if-clauses (m metamodel elements * n references).
>>>
>> Looking at the source code, it seems that these methods are candidates
>> for updating:
>>
>> * org.eclipse.m2m.atl.engine.AtlEMFModelHandler::saveModel (2x)
>> * org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModelElement::eObj ectToASM
>> (says something about using a model as a proxy)
>> * org.eclipse.m2m.atl.drivers.emf4atl.ASMEMFModelElement::isNo tAssignable
>> (change inter-model update procedure?)
>> * org.eclipse.m2m.atl.drivers.emf4atl.EMFModelLoader::realSave
>>
>> Is this list correct?
>>
> Ok, either nobody knows or nobody is interested :(
>
> Regards,
> Rene
--
Mikaël Barbero - PhD Candidate
ATLAS Group (INRIA & LINA) - University of Nantes
2, rue de la Houssinière
44322 Nantes Cedex 3 - France
tel. +33 2 51 12 58 08 /\ cell.+33 6 07 63 19 00
email: Mikael.Barbero@{gmail.com, univ-nantes.fr}
http://www.sciences.univ-nantes.fr/lina/atl/
|
|
|
Goto Forum:
Current Time: Sun Nov 03 12:17:55 GMT 2024
Powered by FUDForum. Page generated in 0.04839 seconds |
] 
Search
Help
Register
Login
Home
