Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » [Acceleo][EMTL] Very strange behaviour of the builder
[Acceleo][EMTL] Very strange behaviour of the builder [message #550376] Fri, 30 July 2010 07:26 Go to next message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 460
Registered: July 2009
Senior Member
Hi,
I have problems with my emtl files (compiled mtl)
and i don't understand what is the problem.

For Gendoc2 (http://gforge.enseeiht.fr/projects/topcased-gendoc/) we use
bundled emtl files to make dynamic dependencies.

We noticed that the acceleo parser can not parse the bundled emtl files
if in the serialization there is references to EPackages using xmi ids
for example http://myEcore/#fezfz456fezvz
but if it is a "common" URI it works (in the serialization) :
http://myEcore/#

And the most weird is if I have two platform my workspace and my runtime:
If i build (indeed if acceleo builds) in my workspace the emtl is
serialized using xmi ids
If i build (indeed if acceleo builds) in my runtime the emtl is
"correctly' serialized.

Do you have any clues about :
Why there is different serializations (the environment seems the same) ?
Why when xmi ids are used the parsing doesn't

To parse we use code generated by Acceleo in a project :

r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "ecore",
new EcoreResourceFactoryImpl());
r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "emtl",
new org.eclipse.acceleo.model.mtl.resource.EMtlResourceFactoryIm pl());
r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t(Resource.Factory.Registry.DEFAULT_EXTENSION,
new XMIResourceFactoryImpl());

r.getPackageRegistry().put(org.eclipse.ocl.ecore.EcorePackag e.eINSTANCE.getNsURI(),
org.eclipse.ocl.ecore.EcorePackage.eINSTANCE);
r.getPackageRegistry().put(org.eclipse.ocl.expressions.Expre ssionsPackage.eINSTANCE.getNsURI(),
org.eclipse.ocl.expressions.ExpressionsPackage.eINSTANCE);
r.getPackageRegistry().put(MtlPackage.eINSTANCE.getNsURI(),
MtlPackage.eINSTANCE);
r.getPackageRegistry().put("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore",
getOCLStdLibPackage());

AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
parser.parse(source, r, ServicesExtension.getInstance().getResources());
// this method retrieves the uris of the dynamic dependencies




Re: [Acceleo][EMTL] Very strange behaviour of the builder [message #550388 is a reply to message #550376] Fri, 30 July 2010 08:33 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 7655
Registered: July 2009
Senior Member
Hi Tristan

Acceleo's support for Reflective models is poor, so you are probably
using a Runtime workspace.

Are you sure that Acceleo is not using the platform:/plugin myEcore
while you or some tool are expecting it to use the platform:/resource
myEcore?

It's very easy to get confused.

Regards

Ed Willink

On 30/07/2010 08:26, Tristan FAURE wrote:
> Hi,
> I have problems with my emtl files (compiled mtl)
> and i don't understand what is the problem.
>
> For Gendoc2 (http://gforge.enseeiht.fr/projects/topcased-gendoc/) we use
> bundled emtl files to make dynamic dependencies.
>
> We noticed that the acceleo parser can not parse the bundled emtl files
> if in the serialization there is references to EPackages using xmi ids
> for example http://myEcore/#fezfz456fezvz
> but if it is a "common" URI it works (in the serialization) :
> http://myEcore/#
>
> And the most weird is if I have two platform my workspace and my runtime:
> If i build (indeed if acceleo builds) in my workspace the emtl is
> serialized using xmi ids
> If i build (indeed if acceleo builds) in my runtime the emtl is
> "correctly' serialized.
>
> Do you have any clues about :
> Why there is different serializations (the environment seems the same) ?
> Why when xmi ids are used the parsing doesn't
>
> To parse we use code generated by Acceleo in a project :
>
> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "ecore",
> new EcoreResourceFactoryImpl());
> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "emtl",
> new org.eclipse.acceleo.model.mtl.resource.EMtlResourceFactoryIm pl());
> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t(Resource.Factory.Registry.DEFAULT_EXTENSION,
> new XMIResourceFactoryImpl());
>
> r.getPackageRegistry().put(org.eclipse.ocl.ecore.EcorePackag e.eINSTANCE.getNsURI(),
> org.eclipse.ocl.ecore.EcorePackage.eINSTANCE);
> r.getPackageRegistry().put(org.eclipse.ocl.expressions.Expre ssionsPackage.eINSTANCE.getNsURI(),
> org.eclipse.ocl.expressions.ExpressionsPackage.eINSTANCE);
> r.getPackageRegistry().put(MtlPackage.eINSTANCE.getNsURI(),
> MtlPackage.eINSTANCE);
> r.getPackageRegistry().put("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore",
> getOCLStdLibPackage());
>
> AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
> parser.parse(source, r, ServicesExtension.getInstance().getResources());
> // this method retrieves the uris of the dynamic dependencies
>
Re: [Acceleo][EMTL] Very strange behaviour of the builder [message #550390 is a reply to message #550388] Fri, 30 July 2010 08:41 Go to previous messageGo to next message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 460
Registered: July 2009
Senior Member
Hi Ed,
I will try maybe it's because my plugin embedding the ecore is in my
workspace.

Le 30/07/2010 10:33, Ed Willink a écrit :
> Hi Tristan
>
> Acceleo's support for Reflective models is poor, so you are probably
> using a Runtime workspace.
>
> Are you sure that Acceleo is not using the platform:/plugin myEcore
> while you or some tool are expecting it to use the platform:/resource
> myEcore?
>
> It's very easy to get confused.
>
> Regards
>
> Ed Willink
>
> On 30/07/2010 08:26, Tristan FAURE wrote:
>> Hi,
>> I have problems with my emtl files (compiled mtl)
>> and i don't understand what is the problem.
>>
>> For Gendoc2 (http://gforge.enseeiht.fr/projects/topcased-gendoc/) we use
>> bundled emtl files to make dynamic dependencies.
>>
>> We noticed that the acceleo parser can not parse the bundled emtl files
>> if in the serialization there is references to EPackages using xmi ids
>> for example http://myEcore/#fezfz456fezvz
>> but if it is a "common" URI it works (in the serialization) :
>> http://myEcore/#
>>
>> And the most weird is if I have two platform my workspace and my
>> runtime:
>> If i build (indeed if acceleo builds) in my workspace the emtl is
>> serialized using xmi ids
>> If i build (indeed if acceleo builds) in my runtime the emtl is
>> "correctly' serialized.
>>
>> Do you have any clues about :
>> Why there is different serializations (the environment seems the same) ?
>> Why when xmi ids are used the parsing doesn't
>>
>> To parse we use code generated by Acceleo in a project :
>>
>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "ecore",
>> new EcoreResourceFactoryImpl());
>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "emtl",
>> new org.eclipse.acceleo.model.mtl.resource.EMtlResourceFactoryIm pl());
>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t(Resource.Factory.Registry.DEFAULT_EXTENSION,
>>
>> new XMIResourceFactoryImpl());
>>
>> r.getPackageRegistry().put(org.eclipse.ocl.ecore.EcorePackag e.eINSTANCE.getNsURI(),
>>
>> org.eclipse.ocl.ecore.EcorePackage.eINSTANCE);
>> r.getPackageRegistry().put(org.eclipse.ocl.expressions.Expre ssionsPackage.eINSTANCE.getNsURI(),
>>
>> org.eclipse.ocl.expressions.ExpressionsPackage.eINSTANCE);
>> r.getPackageRegistry().put(MtlPackage.eINSTANCE.getNsURI(),
>> MtlPackage.eINSTANCE);
>> r.getPackageRegistry().put("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore",
>>
>> getOCLStdLibPackage());
>>
>> AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
>> parser.parse(source, r, ServicesExtension.getInstance().getResources());
>> // this method retrieves the uris of the dynamic dependencies
>>
>




Re: [Acceleo][EMTL] Very strange behaviour of the builder [message #550419 is a reply to message #550390] Fri, 30 July 2010 09:56 Go to previous messageGo to next message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1902
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------050904000805020400040709
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Tristan,

We've had no problems so far with XMI IDs... But I must admit I am a
little lost with your problem description :

-----
"And the most weird is if I have two platform my workspace and my runtime:
If i build (indeed if acceleo builds) in my workspace the emtl is
serialized using xmi ids
If i build (indeed if acceleo builds) in my runtime the emtl is
"correctly' serialized. "
-----

I thinks xmi ids is the "correct" serailization of EMF models using xmi
ids ...

-----
"Why there is different serializations (the environment seems the same) ?"
-----

We do not meddle with serialization, EMF is in charge there. If it does
serialize differently, then it would also serialize differently with
plain old ecore models... and either way deserialization should work.

-----
To parse we use code generated by Acceleo in a project :

[...]

"AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
parser.parse(source, r, ServicesExtension.getInstance().getResources());
// this method retrieves the uris of the dynamic dependencies "
-----

We don't generate this. If you wish to compile mtl files to emtl
yourself, you might want to take a look at the class "AcceleoCompiler".
If you need to use the AcceleoParser class, you need to have a good
understanding of the dependencies you need, and be sure to compile them
beforehand.

Laurent Goubet
Obeo

Tristan FAURE wrote:
> Hi Ed,
> I will try maybe it's because my plugin embedding the ecore is in my
> workspace.
>
> Le 30/07/2010 10:33, Ed Willink a écrit :
>> Hi Tristan
>>
>> Acceleo's support for Reflective models is poor, so you are probably
>> using a Runtime workspace.
>>
>> Are you sure that Acceleo is not using the platform:/plugin myEcore
>> while you or some tool are expecting it to use the platform:/resource
>> myEcore?
>>
>> It's very easy to get confused.
>>
>> Regards
>>
>> Ed Willink
>>
>> On 30/07/2010 08:26, Tristan FAURE wrote:
>>> Hi,
>>> I have problems with my emtl files (compiled mtl)
>>> and i don't understand what is the problem.
>>>
>>> For Gendoc2 (http://gforge.enseeiht.fr/projects/topcased-gendoc/) we use
>>> bundled emtl files to make dynamic dependencies.
>>>
>>> We noticed that the acceleo parser can not parse the bundled emtl files
>>> if in the serialization there is references to EPackages using xmi ids
>>> for example http://myEcore/#fezfz456fezvz
>>> but if it is a "common" URI it works (in the serialization) :
>>> http://myEcore/#
>>>
>>> And the most weird is if I have two platform my workspace and my
>>> runtime:
>>> If i build (indeed if acceleo builds) in my workspace the emtl is
>>> serialized using xmi ids
>>> If i build (indeed if acceleo builds) in my runtime the emtl is
>>> "correctly' serialized.
>>>
>>> Do you have any clues about :
>>> Why there is different serializations (the environment seems the same) ?
>>> Why when xmi ids are used the parsing doesn't
>>>
>>> To parse we use code generated by Acceleo in a project :
>>>
>>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "ecore",
>>> new EcoreResourceFactoryImpl());
>>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "emtl",
>>> new org.eclipse.acceleo.model.mtl.resource.EMtlResourceFactoryIm pl());
>>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t(Resource.Factory.Registry.DEFAULT_EXTENSION,
>>>
>>> new XMIResourceFactoryImpl());
>>>
>>> r.getPackageRegistry().put(org.eclipse.ocl.ecore.EcorePackag e.eINSTANCE.getNsURI(),
>>>
>>> org.eclipse.ocl.ecore.EcorePackage.eINSTANCE);
>>> r.getPackageRegistry().put(org.eclipse.ocl.expressions.Expre ssionsPackage.eINSTANCE.getNsURI(),
>>>
>>> org.eclipse.ocl.expressions.ExpressionsPackage.eINSTANCE);
>>> r.getPackageRegistry().put(MtlPackage.eINSTANCE.getNsURI(),
>>> MtlPackage.eINSTANCE);
>>> r.getPackageRegistry().put("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore",
>>>
>>> getOCLStdLibPackage());
>>>
>>> AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
>>> parser.parse(source, r, ServicesExtension.getInstance().getResources());
>>> // this method retrieves the uris of the dynamic dependencies
>>>
>>


--------------050904000805020400040709
Content-Type: text/x-vcard; charset=utf-8;
name="laurent_goubet.vcf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="laurent_goubet.vcf"

YmVnaW46dmNhcmQNCmZuOkxhdXJlbnQgR291YmV0DQpuOkdvdWJldDtMYXVy ZW50DQpvcmc6
PGEgaHJlZj0iaHR0cDovL3d3dy5vYmVvLmZyIj5PYmVvPC9hPg0KZW1haWw7 aW50ZXJuZXQ6
bGF1cmVudC5nb3ViZXRAb2Jlby5mcg0KdXJsOmh0dHA6Ly93d3cub2Jlby5m cg0KdmVyc2lv
bjoyLjENCmVuZDp2Y2FyZA0KDQo=
--------------050904000805020400040709--
Re: [Acceleo][EMTL] Very strange behaviour of the builder [message #551356 is a reply to message #550419] Fri, 06 August 2010 06:38 Go to previous message
Tristan Faure is currently offline Tristan FaureFriend
Messages: 460
Registered: July 2009
Senior Member
Hi, I have checked solution from Ed and it works.
It seems that when EMF serializes the mtl into emtl, the references to
EPackage in the workspace are serialized using xmi-ids (With standard
behavior it doesn't occur)


Tristan

Le 30/07/2010 11:56, Laurent Goubet a écrit :
> Hi Tristan,
>
> We've had no problems so far with XMI IDs... But I must admit I am a
> little lost with your problem description :
>
> -----
> "And the most weird is if I have two platform my workspace and my
> runtime:
> If i build (indeed if acceleo builds) in my workspace the emtl is
> serialized using xmi ids
> If i build (indeed if acceleo builds) in my runtime the emtl is
> "correctly' serialized. "
> -----
>
> I thinks xmi ids is the "correct" serailization of EMF models using
> xmi ids ...
>
> -----
> "Why there is different serializations (the environment seems the
> same) ?"
> -----
>
> We do not meddle with serialization, EMF is in charge there. If it
> does serialize differently, then it would also serialize differently
> with plain old ecore models... and either way deserialization should
> work.
>
> -----
> To parse we use code generated by Acceleo in a project :
>
> [...]
>
> "AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
> parser.parse(source, r,
> ServicesExtension.getInstance().getResources()); // this method
> retrieves the uris of the dynamic dependencies "
> -----
>
> We don't generate this. If you wish to compile mtl files to emtl
> yourself, you might want to take a look at the class
> "AcceleoCompiler". If you need to use the AcceleoParser class, you
> need to have a good understanding of the dependencies you need, and be
> sure to compile them beforehand.
>
> Laurent Goubet
> Obeo
>
> Tristan FAURE wrote:
>> Hi Ed,
>> I will try maybe it's because my plugin embedding the ecore is in my
>> workspace.
>>
>> Le 30/07/2010 10:33, Ed Willink a écrit :
>>> Hi Tristan
>>>
>>> Acceleo's support for Reflective models is poor, so you are probably
>>> using a Runtime workspace.
>>>
>>> Are you sure that Acceleo is not using the platform:/plugin myEcore
>>> while you or some tool are expecting it to use the
>>> platform:/resource myEcore?
>>>
>>> It's very easy to get confused.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>> On 30/07/2010 08:26, Tristan FAURE wrote:
>>>> Hi,
>>>> I have problems with my emtl files (compiled mtl)
>>>> and i don't understand what is the problem.
>>>>
>>>> For Gendoc2 (http://gforge.enseeiht.fr/projects/topcased-gendoc/)
>>>> we use
>>>> bundled emtl files to make dynamic dependencies.
>>>>
>>>> We noticed that the acceleo parser can not parse the bundled emtl
>>>> files
>>>> if in the serialization there is references to EPackages using xmi ids
>>>> for example http://myEcore/#fezfz456fezvz
>>>> but if it is a "common" URI it works (in the serialization) :
>>>> http://myEcore/#
>>>>
>>>> And the most weird is if I have two platform my workspace and my
>>>> runtime:
>>>> If i build (indeed if acceleo builds) in my workspace the emtl is
>>>> serialized using xmi ids
>>>> If i build (indeed if acceleo builds) in my runtime the emtl is
>>>> "correctly' serialized.
>>>>
>>>> Do you have any clues about :
>>>> Why there is different serializations (the environment seems the
>>>> same) ?
>>>> Why when xmi ids are used the parsing doesn't
>>>>
>>>> To parse we use code generated by Acceleo in a project :
>>>>
>>>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "ecore",
>>>> new EcoreResourceFactoryImpl());
>>>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t( "emtl",
>>>> new org.eclipse.acceleo.model.mtl.resource.EMtlResourceFactoryIm pl());
>>>> r.getResourceFactoryRegistry().getExtensionToFactoryMap().pu t(Resource.Factory.Registry.DEFAULT_EXTENSION,
>>>>
>>>> new XMIResourceFactoryImpl());
>>>>
>>>> r.getPackageRegistry().put(org.eclipse.ocl.ecore.EcorePackag e.eINSTANCE.getNsURI(),
>>>>
>>>> org.eclipse.ocl.ecore.EcorePackage.eINSTANCE);
>>>> r.getPackageRegistry().put(org.eclipse.ocl.expressions.Expre ssionsPackage.eINSTANCE.getNsURI(),
>>>>
>>>> org.eclipse.ocl.expressions.ExpressionsPackage.eINSTANCE);
>>>> r.getPackageRegistry().put(MtlPackage.eINSTANCE.getNsURI(),
>>>> MtlPackage.eINSTANCE);
>>>> r.getPackageRegistry().put("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore",
>>>>
>>>> getOCLStdLibPackage());
>>>>
>>>> AcceleoSourceBuffer source = new AcceleoSourceBuffer(textBuffer);
>>>> parser.parse(source, r,
>>>> ServicesExtension.getInstance().getResources());
>>>> // this method retrieves the uris of the dynamic dependencies
>>>>
>>>
>




Previous Topic:Changing outlet path from within Xpand or Xtend
Next Topic:[Xpand2] Where can I find CppBeautifier / org.eclipse.xpand.support.cdt ?
Goto Forum:
  


Current Time: Thu Mar 28 12:51:17 GMT 2024

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

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

Back to the top