Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » AMW » Re: Refactoring deprecated AM3 branch and AMW model handler to use ATL 3.0 API
Re: Refactoring deprecated AM3 branch and AMW model handler to use ATL 3.0 API [message #484134] Fri, 04 September 2009 08:22 Go to next message
Hugo Bruneliere is currently offline Hugo Bruneliere
Messages: 601
Registered: July 2009
Senior Member
Hi Juan Pedro,

Juan Pedro Silva a écrit :
> Thank you very much, Hugo.
> I ended up with this piece of code (let me know if you consider it
> appropriated):
>
> try
> {
> //AtlVM.getVM(vm).launch(asmUrl, libs, models, params,
> superimps, options);
> //AtlLauncher.getDefault().launch(asmUrl, libs, models,
> params, superimps, options);
> ASM asm = new ASMXMLReader().read(new
> BufferedInputStream(asmUrl.openStream()));
> superimps.add(0, asm); //New ILauncher.launch(..) method
> takes a list of modules where the first module of the set is overriden
> by the next ones
> ILauncher atlL =
> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
> atlL.launch(ILauncher.RUN_MODE, new
> NullProgressMonitor(), options, superimps);
> } catch (IOException e)
> {
> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(), e);
> } catch (ATLCoreException e) {
> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(), e);
> e.printStackTrace();
> }
>
> I will do a partial test of my refactorization with an AMW
> refactorization I'm also performing (it may take a while, though, as I
> have other thing in hand).
> Perhaps (if you already have test suites for AM3) you may like me to
> send it to you so you could start testing it already?. Just let me know.

Unfortunately, as we are not continuing the development of these
plug-ins anymore, we don't have such a test suite. However, one simple
way of validating your new implementation is to manually test each of
the injectors, extractors, and other converters (concerning KM3, ATL,
XML, etc) on a given set of files/models/metamodels. Thus, you will be
able to ensure that the general behavior of these plug-ins has not been
altered.

Similarly, for AMW, you can try to run some of the use cases available
from the AMW website using both ATL 3.0 and your new implementation of
the AMW model handler.

>
> How is everyone in EDM-Nantes?, send my regards.
> Merçi ;-),

Everything goes well at EMN. Thanks!

Cheers,

Hugo

> Juan Pedro
>
>
> Hugo Bruneliere escribió:
>> Hi Juan,
>>
>> Juan Pedro Silva a écrit :
>>> Hi Hugo, thank you for your support.
>>> If I take the mentioned approach, the following instruction:
>>>
>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params, superimps,
>>> options);
>>>
>>> Is no longer supported (AtlVM is no longer there in ATL 3.0), so I
>>> need a suggestion in how to rewrite that instruction.
>>> These alternatives might work, but not sure which is best:
>>>
>>> RegularVMLauncher.launch(java.lang.String mode,
>>>
>>> org.eclipse.core.runtime.IProgressMonitor monitor,
>>>
>>> java.util.Map<java.lang.String,java.lang.Object> options,
>>> java.lang.Object... modules);
>>>
>>> or
>>>
>>> AtlLauncher.getDefault().launch(java.net.URL asmurl, java.util.Map
>>> libraries, java.util.Map models, java.util.Map asmParams,
>>> java.util.List superimpose, java.util.Map options)
>>>
>>> The first alternative is using the regular VM, but parameters are not
>>> the same, and as documentation is scarce, I don't know how to convert
>>> them.
>>> On the other side, the second alternative takes the same parameters,
>>> but my feeling is that it will use the new VM (as it is the default
>>> one), and not regular VM.
>>> There may be other (more correct) alternatives, but I'm not
>>> acquainted with the new API, and those are the ones I found so far.
>>> Do you have any suggestions for this instruction?.
>>
>> In order to get the launcher of the Regular VM (but which conforms to
>> the new ILauncher interface), you can use the "getLauncher()" method
>> of the org.eclipse.m2m.atl.core.service.CoreService class:
>>
>> ILauncher atlLauncher =
>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>> //of course, ATLLaunchConstants.EMF_VM_NAME also exists
>> atlLauncher.launch(...);
>>
>> Cheers,
>>
>> Hugo
>>
>>>
>>> I'll love to contribute once I finish refactoring.
>>> Thanks for your help.
>>> Regards,
>>> Juan Pedro
>>>
>>> Hugo Bruneliere escribió:
>>>> Hi Juan,
>>>>
>>>> First, thank you very much for your contribution. I'm sure it will
>>>> be used by many AM3 & ATL developers :-)
>>>>
>>>> Juan Pedro Silva a écrit :
>>>>> Hi everybody, I'm trying to rewrite some parts of AM3's deprecated
>>>>> packages branch to use ATL 3.0.
>>>>> I have managed to modify most parts to use the new API, but I have
>>>>> doubts on a particular piece of code.
>>>>> The code in hands is in class
>>>>> org.eclipse.gmt.am3.tools.ant.ATLModelTransformationTask, and is
>>>>> this one:
>>>>>
>>>>> ...
>>>>> if(vm == null)
>>>>> vm = AtlVM.ATLVM_REGULAR; ...
>>>>> if (!debug.booleanValue())
>>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params,
>>>>> superimps, options);
>>>>> ...
>>>>>
>>>>> I guess I can rewrite the first red line as
>>>>> vm = ATLLaunchConstants.REGULAR_VM_NAME;
>>>>>
>>>>> but I don't believe this is the correct way to go, I think I should
>>>>> change the structure somehow.
>>>>> Can anyone give me a pointer on this?.
>>>>
>>>> From my point of view, what you propose is good because it keeps
>>>> exactly the same behavior as the previous version. I don't think it
>>>> is necessary to modify the current structure of the plugin, at least
>>>> in a first time.
>>>>
>>>> Of course, it would be great if you could contribute your upgrades
>>>> by submitting a patch via Bugzilla!
>>>>
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>>> Thanks,
>>>>> Juan Pedro
>>>>
>>>>
>>
>>


--
-------------------------------------------------
Hugo Bruneliere - R&D Engineer
AtlanMod research team (INRIA & EMN) - Room B206
École des Mines de Nantes
4, rue Alfred Kastler
44307 Nantes Cedex 3 - France
Office: +33 (0)2 51 85 82 21
EMail: hugo.bruneliere@inria.fr
-------------------------------------------------


------------------------------------------
Hugo Bruneliere - R&D Engineer
AtlanMod research team (Inria, EMN & LINA)
Ecole des Mines de Nantes
Nantes - France
------------------------------------------
Re: Refactoring deprecated AM3 branch and AMW model handler to use ATL 3.0 API [message #487147 is a reply to message #484134] Tue, 22 September 2009 03:26 Go to previous messageGo to next message
Kelly Garces is currently offline Kelly Garces
Messages: 39
Registered: July 2009
Member
Hi Juan Pedro,

I am wondering whether you have checked the AmwModelHandler behavior on
ATL 3.0?
After some experimentations, it seems to me the handler methods are not
available in ATL 3.0. Do you plan to settle these functionalities?

Regards,

Hugo Bruneliere a écrit :
> Hi Juan Pedro,
>
> Juan Pedro Silva a écrit :
>> Thank you very much, Hugo.
>> I ended up with this piece of code (let me know if you consider it
>> appropriated):
>>
>> try
>> {
>> //AtlVM.getVM(vm).launch(asmUrl, libs, models, params,
>> superimps, options);
>> //AtlLauncher.getDefault().launch(asmUrl, libs,
>> models, params, superimps, options);
>> ASM asm = new ASMXMLReader().read(new
>> BufferedInputStream(asmUrl.openStream()));
>> superimps.add(0, asm); //New ILauncher.launch(..) method takes a list
>> of modules where the first module of the set is overriden by the next
>> ones
>> ILauncher atlL =
>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>> atlL.launch(ILauncher.RUN_MODE, new
>> NullProgressMonitor(), options, superimps);
>> } catch (IOException e)
>> {
>> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(), e);
>> } catch (ATLCoreException e) {
>> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(), e);
>> e.printStackTrace();
>> }
>>
>> I will do a partial test of my refactorization with an AMW
>> refactorization I'm also performing (it may take a while, though, as I
>> have other thing in hand).
>> Perhaps (if you already have test suites for AM3) you may like me to
>> send it to you so you could start testing it already?. Just let me know.
>
> Unfortunately, as we are not continuing the development of these
> plug-ins anymore, we don't have such a test suite. However, one simple
> way of validating your new implementation is to manually test each of
> the injectors, extractors, and other converters (concerning KM3, ATL,
> XML, etc) on a given set of files/models/metamodels. Thus, you will be
> able to ensure that the general behavior of these plug-ins has not been
> altered.
>
> Similarly, for AMW, you can try to run some of the use cases available
> from the AMW website using both ATL 3.0 and your new implementation of
> the AMW model handler.
>
>>
>> How is everyone in EDM-Nantes?, send my regards.
>> Merçi ;-),
>
> Everything goes well at EMN. Thanks!
>
> Cheers,
>
> Hugo
>
>> Juan Pedro
>>
>>
>> Hugo Bruneliere escribió:
>>> Hi Juan,
>>>
>>> Juan Pedro Silva a écrit :
>>>> Hi Hugo, thank you for your support.
>>>> If I take the mentioned approach, the following instruction:
>>>>
>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params, superimps,
>>>> options);
>>>>
>>>> Is no longer supported (AtlVM is no longer there in ATL 3.0), so I
>>>> need a suggestion in how to rewrite that instruction.
>>>> These alternatives might work, but not sure which is best:
>>>>
>>>> RegularVMLauncher.launch(java.lang.String mode,
>>>>
>>>> org.eclipse.core.runtime.IProgressMonitor monitor,
>>>>
>>>> java.util.Map<java.lang.String,java.lang.Object> options,
>>>> java.lang.Object... modules);
>>>>
>>>> or
>>>>
>>>> AtlLauncher.getDefault().launch(java.net.URL asmurl, java.util.Map
>>>> libraries, java.util.Map models, java.util.Map asmParams,
>>>> java.util.List superimpose, java.util.Map options)
>>>>
>>>> The first alternative is using the regular VM, but parameters are
>>>> not the same, and as documentation is scarce, I don't know how to
>>>> convert them.
>>>> On the other side, the second alternative takes the same parameters,
>>>> but my feeling is that it will use the new VM (as it is the default
>>>> one), and not regular VM.
>>>> There may be other (more correct) alternatives, but I'm not
>>>> acquainted with the new API, and those are the ones I found so far.
>>>> Do you have any suggestions for this instruction?.
>>>
>>> In order to get the launcher of the Regular VM (but which conforms to
>>> the new ILauncher interface), you can use the "getLauncher()" method
>>> of the org.eclipse.m2m.atl.core.service.CoreService class:
>>>
>>> ILauncher atlLauncher =
>>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>>> //of course, ATLLaunchConstants.EMF_VM_NAME also exists
>>> atlLauncher.launch(...);
>>> Cheers,
>>>
>>> Hugo
>>>
>>>>
>>>> I'll love to contribute once I finish refactoring.
>>>> Thanks for your help.
>>>> Regards,
>>>> Juan Pedro
>>>>
>>>> Hugo Bruneliere escribió:
>>>>> Hi Juan,
>>>>>
>>>>> First, thank you very much for your contribution. I'm sure it will
>>>>> be used by many AM3 & ATL developers :-)
>>>>>
>>>>> Juan Pedro Silva a écrit :
>>>>>> Hi everybody, I'm trying to rewrite some parts of AM3's deprecated
>>>>>> packages branch to use ATL 3.0.
>>>>>> I have managed to modify most parts to use the new API, but I have
>>>>>> doubts on a particular piece of code.
>>>>>> The code in hands is in class
>>>>>> org.eclipse.gmt.am3.tools.ant.ATLModelTransformationTask, and is
>>>>>> this one:
>>>>>>
>>>>>> ...
>>>>>> if(vm == null)
>>>>>> vm = AtlVM.ATLVM_REGULAR; ...
>>>>>> if (!debug.booleanValue())
>>>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params,
>>>>>> superimps, options);
>>>>>> ...
>>>>>>
>>>>>> I guess I can rewrite the first red line as
>>>>>> vm = ATLLaunchConstants.REGULAR_VM_NAME;
>>>>>>
>>>>>> but I don't believe this is the correct way to go, I think I
>>>>>> should change the structure somehow.
>>>>>> Can anyone give me a pointer on this?.
>>>>>
>>>>> From my point of view, what you propose is good because it keeps
>>>>> exactly the same behavior as the previous version. I don't think it
>>>>> is necessary to modify the current structure of the plugin, at
>>>>> least in a first time.
>>>>>
>>>>> Of course, it would be great if you could contribute your upgrades
>>>>> by submitting a patch via Bugzilla!
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Hugo
>>>>>
>>>>>> Thanks,
>>>>>> Juan Pedro
>>>>>
>>>>>
>>>
>>>
>
>


--
Kelly Garces - Phd. student
AtlanMod & AsCoLa research teams
École des Mines de Nantes
4, rue Alfred Kastler
44307 Nantes Cedex 3 - France
Re: Refactoring deprecated AM3 branch and AMW model handler to use ATL 3.0 API [message #490087 is a reply to message #487147] Wed, 07 October 2009 05:43 Go to previous messageGo to next message
Hugo Bruneliere is currently offline Hugo Bruneliere
Messages: 601
Registered: July 2009
Senior Member
Hi Juan Pedro,

Do you have some latest news on your refactoring work around AMW and
"old" AM3?
Is it still in progress?

Please, don't hesitate if you need any specific information from our side.

Best regards,

Hugo

Kelly Garces a écrit :
> Hi Juan Pedro,
>
> I am wondering whether you have checked the AmwModelHandler behavior on
> ATL 3.0?
> After some experimentations, it seems to me the handler methods are not
> available in ATL 3.0. Do you plan to settle these functionalities?
>
> Regards,
>
> Hugo Bruneliere a écrit :
>> Hi Juan Pedro,
>>
>> Juan Pedro Silva a écrit :
>>> Thank you very much, Hugo.
>>> I ended up with this piece of code (let me know if you consider it
>>> appropriated):
>>>
>>> try
>>> {
>>> //AtlVM.getVM(vm).launch(asmUrl, libs, models,
>>> params, superimps, options);
>>> //AtlLauncher.getDefault().launch(asmUrl, libs,
>>> models, params, superimps, options);
>>> ASM asm = new ASMXMLReader().read(new
>>> BufferedInputStream(asmUrl.openStream()));
>>> superimps.add(0, asm); //New ILauncher.launch(..) method takes a list
>>> of modules where the first module of the set is overriden by the next
>>> ones
>>> ILauncher atlL =
>>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>>> atlL.launch(ILauncher.RUN_MODE, new
>>> NullProgressMonitor(), options, superimps);
>>> } catch (IOException e)
>>> {
>>> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(), e);
>>> } catch (ATLCoreException e) {
>>> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(), e);
>>> e.printStackTrace();
>>> }
>>>
>>> I will do a partial test of my refactorization with an AMW
>>> refactorization I'm also performing (it may take a while, though, as
>>> I have other thing in hand).
>>> Perhaps (if you already have test suites for AM3) you may like me to
>>> send it to you so you could start testing it already?. Just let me know.
>>
>> Unfortunately, as we are not continuing the development of these
>> plug-ins anymore, we don't have such a test suite. However, one simple
>> way of validating your new implementation is to manually test each of
>> the injectors, extractors, and other converters (concerning KM3, ATL,
>> XML, etc) on a given set of files/models/metamodels. Thus, you will be
>> able to ensure that the general behavior of these plug-ins has not
>> been altered.
>>
>> Similarly, for AMW, you can try to run some of the use cases available
>> from the AMW website using both ATL 3.0 and your new implementation of
>> the AMW model handler.
>>
>>>
>>> How is everyone in EDM-Nantes?, send my regards.
>>> Merçi ;-),
>>
>> Everything goes well at EMN. Thanks!
>>
>> Cheers,
>>
>> Hugo
>>
>>> Juan Pedro
>>>
>>>
>>> Hugo Bruneliere escribió:
>>>> Hi Juan,
>>>>
>>>> Juan Pedro Silva a écrit :
>>>>> Hi Hugo, thank you for your support.
>>>>> If I take the mentioned approach, the following instruction:
>>>>>
>>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params, superimps,
>>>>> options);
>>>>>
>>>>> Is no longer supported (AtlVM is no longer there in ATL 3.0), so I
>>>>> need a suggestion in how to rewrite that instruction.
>>>>> These alternatives might work, but not sure which is best:
>>>>>
>>>>> RegularVMLauncher.launch(java.lang.String mode,
>>>>>
>>>>> org.eclipse.core.runtime.IProgressMonitor monitor,
>>>>>
>>>>> java.util.Map<java.lang.String,java.lang.Object> options,
>>>>> java.lang.Object... modules);
>>>>>
>>>>> or
>>>>>
>>>>> AtlLauncher.getDefault().launch(java.net.URL asmurl, java.util.Map
>>>>> libraries, java.util.Map models, java.util.Map asmParams,
>>>>> java.util.List superimpose, java.util.Map options)
>>>>>
>>>>> The first alternative is using the regular VM, but parameters are
>>>>> not the same, and as documentation is scarce, I don't know how to
>>>>> convert them.
>>>>> On the other side, the second alternative takes the same
>>>>> parameters, but my feeling is that it will use the new VM (as it is
>>>>> the default one), and not regular VM.
>>>>> There may be other (more correct) alternatives, but I'm not
>>>>> acquainted with the new API, and those are the ones I found so far.
>>>>> Do you have any suggestions for this instruction?.
>>>>
>>>> In order to get the launcher of the Regular VM (but which conforms
>>>> to the new ILauncher interface), you can use the "getLauncher()"
>>>> method of the org.eclipse.m2m.atl.core.service.CoreService class:
>>>>
>>>> ILauncher atlLauncher =
>>>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>>>> //of course, ATLLaunchConstants.EMF_VM_NAME also exists
>>>> atlLauncher.launch(...);
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>>>
>>>>> I'll love to contribute once I finish refactoring.
>>>>> Thanks for your help.
>>>>> Regards,
>>>>> Juan Pedro
>>>>>
>>>>> Hugo Bruneliere escribió:
>>>>>> Hi Juan,
>>>>>>
>>>>>> First, thank you very much for your contribution. I'm sure it will
>>>>>> be used by many AM3 & ATL developers :-)
>>>>>>
>>>>>> Juan Pedro Silva a écrit :
>>>>>>> Hi everybody, I'm trying to rewrite some parts of AM3's
>>>>>>> deprecated packages branch to use ATL 3.0.
>>>>>>> I have managed to modify most parts to use the new API, but I
>>>>>>> have doubts on a particular piece of code.
>>>>>>> The code in hands is in class
>>>>>>> org.eclipse.gmt.am3.tools.ant.ATLModelTransformationTask, and is
>>>>>>> this one:
>>>>>>>
>>>>>>> ...
>>>>>>> if(vm == null)
>>>>>>> vm = AtlVM.ATLVM_REGULAR; ...
>>>>>>> if (!debug.booleanValue())
>>>>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params,
>>>>>>> superimps, options);
>>>>>>> ...
>>>>>>>
>>>>>>> I guess I can rewrite the first red line as
>>>>>>> vm = ATLLaunchConstants.REGULAR_VM_NAME;
>>>>>>>
>>>>>>> but I don't believe this is the correct way to go, I think I
>>>>>>> should change the structure somehow.
>>>>>>> Can anyone give me a pointer on this?.
>>>>>>
>>>>>> From my point of view, what you propose is good because it keeps
>>>>>> exactly the same behavior as the previous version. I don't think
>>>>>> it is necessary to modify the current structure of the plugin, at
>>>>>> least in a first time.
>>>>>>
>>>>>> Of course, it would be great if you could contribute your upgrades
>>>>>> by submitting a patch via Bugzilla!
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Hugo
>>>>>>
>>>>>>> Thanks,
>>>>>>> Juan Pedro
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>


--
-------------------------------------------------
Hugo Bruneliere - R&D Engineer
AtlanMod research team (INRIA & EMN) - Room B206
Ecole des Mines de Nantes
4, rue Alfred Kastler
44307 Nantes Cedex 3 - France
Office: +33 (0)2 51 85 82 21
EMail: hugo.bruneliere@inria.fr
-------------------------------------------------


------------------------------------------
Hugo Bruneliere - R&D Engineer
AtlanMod research team (Inria, EMN & LINA)
Ecole des Mines de Nantes
Nantes - France
------------------------------------------
Re: Refactoring deprecated AM3 branch and AMW model handler to use ATL 3.0 API [message #491708 is a reply to message #487147] Thu, 15 October 2009 10:08 Go to previous message
Juan Pedro Silva is currently offline Juan Pedro Silva
Messages: 258
Registered: July 2009
Senior Member
Sorry Kelly and Hugo for not responding this earlier.
Hugo already contacted me, so I believe you are tracking this issue back
in INRIA now.
I'm posting this so everybody else knnows it's still ongoing.
Best regards,
Juan Pedro

Kelly Garces escribió:
> Hi Juan Pedro,
>
> I am wondering whether you have checked the AmwModelHandler behavior
> on ATL 3.0?
> After some experimentations, it seems to me the handler methods are
> not available in ATL 3.0. Do you plan to settle these functionalities?
>
> Regards,
>
> Hugo Bruneliere a écrit :
>> Hi Juan Pedro,
>>
>> Juan Pedro Silva a écrit :
>>> Thank you very much, Hugo.
>>> I ended up with this piece of code (let me know if you consider it
>>> appropriated):
>>>
>>> try
>>> {
>>> //AtlVM.getVM(vm).launch(asmUrl, libs, models,
>>> params, superimps, options);
>>> //AtlLauncher.getDefault().launch(asmUrl, libs,
>>> models, params, superimps, options);
>>> ASM asm = new ASMXMLReader().read(new
>>> BufferedInputStream(asmUrl.openStream()));
>>> superimps.add(0, asm); //New ILauncher.launch(..) method takes a
>>> list of modules where the first module of the set is overriden by
>>> the next ones
>>> ILauncher atlL =
>>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>>> atlL.launch(ILauncher.RUN_MODE, new
>>> NullProgressMonitor(), options, superimps);
>>> } catch (IOException e)
>>> {
>>> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(),
>>> e);
>>> } catch (ATLCoreException e) {
>>> ATLLogger.log(Level.SEVERE, e.getLocalizedMessage(),
>>> e);
>>> e.printStackTrace();
>>> }
>>>
>>> I will do a partial test of my refactorization with an AMW
>>> refactorization I'm also performing (it may take a while, though, as
>>> I have other thing in hand).
>>> Perhaps (if you already have test suites for AM3) you may like me to
>>> send it to you so you could start testing it already?. Just let me
>>> know.
>>
>> Unfortunately, as we are not continuing the development of these
>> plug-ins anymore, we don't have such a test suite. However, one
>> simple way of validating your new implementation is to manually test
>> each of the injectors, extractors, and other converters (concerning
>> KM3, ATL, XML, etc) on a given set of files/models/metamodels. Thus,
>> you will be able to ensure that the general behavior of these
>> plug-ins has not been altered.
>>
>> Similarly, for AMW, you can try to run some of the use cases
>> available from the AMW website using both ATL 3.0 and your new
>> implementation of the AMW model handler.
>>
>>>
>>> How is everyone in EDM-Nantes?, send my regards.
>>> Merçi ;-),
>>
>> Everything goes well at EMN. Thanks!
>>
>> Cheers,
>>
>> Hugo
>>
>>> Juan Pedro
>>>
>>>
>>> Hugo Bruneliere escribió:
>>>> Hi Juan,
>>>>
>>>> Juan Pedro Silva a écrit :
>>>>> Hi Hugo, thank you for your support.
>>>>> If I take the mentioned approach, the following instruction:
>>>>>
>>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params, superimps,
>>>>> options);
>>>>>
>>>>> Is no longer supported (AtlVM is no longer there in ATL 3.0), so I
>>>>> need a suggestion in how to rewrite that instruction.
>>>>> These alternatives might work, but not sure which is best:
>>>>>
>>>>> RegularVMLauncher.launch(java.lang.String mode,
>>>>>
>>>>> org.eclipse.core.runtime.IProgressMonitor monitor,
>>>>>
>>>>> java.util.Map<java.lang.String,java.lang.Object> options,
>>>>> java.lang.Object... modules);
>>>>>
>>>>> or
>>>>>
>>>>> AtlLauncher.getDefault().launch(java.net.URL asmurl, java.util.Map
>>>>> libraries, java.util.Map models, java.util.Map asmParams,
>>>>> java.util.List superimpose, java.util.Map options)
>>>>>
>>>>> The first alternative is using the regular VM, but parameters are
>>>>> not the same, and as documentation is scarce, I don't know how to
>>>>> convert them.
>>>>> On the other side, the second alternative takes the same
>>>>> parameters, but my feeling is that it will use the new VM (as it
>>>>> is the default one), and not regular VM.
>>>>> There may be other (more correct) alternatives, but I'm not
>>>>> acquainted with the new API, and those are the ones I found so far.
>>>>> Do you have any suggestions for this instruction?.
>>>>
>>>> In order to get the launcher of the Regular VM (but which conforms
>>>> to the new ILauncher interface), you can use the "getLauncher()"
>>>> method of the org.eclipse.m2m.atl.core.service.CoreService class:
>>>>
>>>> ILauncher atlLauncher =
>>>> CoreService.getLauncher(ATLLaunchConstants.REGULAR_VM_NAME);
>>>> //of course, ATLLaunchConstants.EMF_VM_NAME also exists
>>>> atlLauncher.launch(...);
>>>> Cheers,
>>>>
>>>> Hugo
>>>>
>>>>>
>>>>> I'll love to contribute once I finish refactoring.
>>>>> Thanks for your help.
>>>>> Regards,
>>>>> Juan Pedro
>>>>>
>>>>> Hugo Bruneliere escribió:
>>>>>> Hi Juan,
>>>>>>
>>>>>> First, thank you very much for your contribution. I'm sure it
>>>>>> will be used by many AM3 & ATL developers :-)
>>>>>>
>>>>>> Juan Pedro Silva a écrit :
>>>>>>> Hi everybody, I'm trying to rewrite some parts of AM3's
>>>>>>> deprecated packages branch to use ATL 3.0.
>>>>>>> I have managed to modify most parts to use the new API, but I
>>>>>>> have doubts on a particular piece of code.
>>>>>>> The code in hands is in class
>>>>>>> org.eclipse.gmt.am3.tools.ant.ATLModelTransformationTask, and is
>>>>>>> this one:
>>>>>>>
>>>>>>> ...
>>>>>>> if(vm == null)
>>>>>>> vm = AtlVM.ATLVM_REGULAR; ...
>>>>>>> if (!debug.booleanValue())
>>>>>>> AtlVM.getVM(vm).launch(asmUrl, libs, models, params,
>>>>>>> superimps, options);
>>>>>>> ...
>>>>>>>
>>>>>>> I guess I can rewrite the first red line as
>>>>>>> vm = ATLLaunchConstants.REGULAR_VM_NAME;
>>>>>>>
>>>>>>> but I don't believe this is the correct way to go, I think I
>>>>>>> should change the structure somehow.
>>>>>>> Can anyone give me a pointer on this?.
>>>>>>
>>>>>> From my point of view, what you propose is good because it keeps
>>>>>> exactly the same behavior as the previous version. I don't think
>>>>>> it is necessary to modify the current structure of the plugin, at
>>>>>> least in a first time.
>>>>>>
>>>>>> Of course, it would be great if you could contribute your
>>>>>> upgrades by submitting a patch via Bugzilla!
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Hugo
>>>>>>
>>>>>>> Thanks,
>>>>>>> Juan Pedro
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
>
>
Previous Topic:Migrating AMW to use ATL 3.0 API.
Next Topic:Create Weaving Model from Transformation
Goto Forum:
  


Current Time: Fri Aug 22 15:58:35 EDT 2014

Powered by FUDForum. Page generated in 0.03267 seconds