Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » [Acceleo] PDE, Ant build and Acceleo(Compiler)
[Acceleo] PDE, Ant build and Acceleo(Compiler) [message #720823] Wed, 31 August 2011 09:54 Go to next message
Brice Pajot is currently offline Brice PajotFriend
Messages: 4
Registered: June 2011
Junior Member
Hi,

Got a new problem while using Acceleo in a product build using PDE on an Eclipse Indigo. I will try to be concise:
I defined several Acceleo generator plugins where some of them include others templates (e.g., I defined a util module that is shared by several others), and one template of one module extends a template of another plugin.

Everything works fine in an Eclipse instance mode, but once built, my product does not behave in the same way: most of the generated material does not perform nicely since Acceleo runtime seems to meet some problems while resolving dependencies (this is my guess).

I tried to track a bit where the problem could come from, but I must admit that I cannot explain all the problems I meet in providing a working product... If you can enlighten me on the few following points that seems related to these problems:

1) Since my problem seems to come from dependency resolution, I looked at the AcceleoHelper.setDependencies(String) method; the latter seems to look for a best candidate in declared dependencies. When using pde build, the target folder is the location where all the plugins are stored. The method provides a combination of reverse-alphabetical sorting on the names of the plugin directories, and a startsWith matching. This behavior leads to matching plugin with id a.b.c to any plugin with id a.b.c.x. Unfortunately, when my EMF model-plugin is set in dependencies, the dependency is not set on the correct plugin.
(As a side-effect of the method, I also wonder if using the last segment of the path for the dependency-id is not problematic regarding the plugin-id which could be different)

2) Trying to override the behavior of this method to better match my plugins did not lead me to a working product, but now the pde-build do not raise Acceleo compilation errors. The next point I looked at was AcceleoCompilerHelper.computeDependencies(...) which maps dependencies on URIs. Still using PDE build, this phase seems to solve URIs on "platform :// plugin" URIs which seems fine. However, the resulting transformation provides URIs of the form "platform :// plugin/BUNDLE_ID/@dot/path_to_emtl". I usually do not work with this kind of URIs but I would expect that the @dot is not present in this URIs to be solved correctly. Maybe it's a bad guess since in some cases, Acceleo templates seems to work correctly, and that's one of my problem since I cannot highlight a consistent behavior.

3) Tried to hack this method to remove the @dot segment. Now the compilation seems to work and also the product!... but only using an XMI serialization. This point is maybe due to a side effect of the point 1). Changing the resolution of dependencies paths generated a side-effect on loadEcoreFiles(...) which uses dependency paths to look at a plugin-provided metamodel. Since, It now correctly solves the plugin a.b.c of my metamodel, it seems to register the URI of my metamodel as a local location instead of an "http ://a.b.c" URI. This point made me think that the previous matching was maybe made on purpose since this impact seems major on the resulting behavior... However, I did not dig further in this way since the XMI serialization seems to bring me a workaround (I just lost the efficiency of generation). But maybe I introduced some nasty side-effects I do not see yet... Just note that the behavior of the XMI and binary serializations seems different; I think I read a thread or a bug on that point.

4) One last point with XMI serialization. The output of the EMTL file can be selected on the properties of the Acceleo project, providing the chosen-format EMTL file in the workspace. However, the "build.acceleo" file used by ant build seems to use a parameter "binaryResource" which I would guess as related to this option. However, the builder and the underlying Acceleo-template seems to set this parameter to "true" whatever the option of the project is. Shouldn't it this parameter related to the options of the projects?

A last note on my environment: I use my metamodel as a compiled Eclipse plugin; the plugin is also present in my workspace. I tried the previous steps either with the default version of Acceleo provided with Eclipse 3.7 and also with the last hudson build.
So maybe I am completely wrong in my practices of Acceleo and you can point me on some other best-practices for providing Acceleo generation as a part of a product build, or maybe you can point on a best way of managing dependencies between plugins.

Thanks for your help (... and reading until there) !

(sorry for spaces in URIs but I am not allowed to post links since I did not post enough messages)
Re: [Acceleo] PDE, Ant build and Acceleo(Compiler) [message #720881 is a reply to message #720823] Wed, 31 August 2011 12:33 Go to previous messageGo to next message
Stephane Begaudeau is currently offline Stephane BegaudeauFriend
Messages: 458
Registered: April 2010
Location: Nantes (France)
Senior Member

Hi,

1) There may be indeed a problem with the algorithm, I'll have a look. You can override it to adapt to it to the need of your build as you did.

2) I remember that someone had encountered an uri with a "@dot" before, I don't remember how the problem appeared but if I recall correctly it was coming from "${target.folder}" which contained this "@dot". Do you have the line "outputFolder=${target.folder}" below the sourceFolder one?.

3) The XMI based serialization is (without entering too much in the details) smarter to handle URIs compared to the binary one but the binary resource is smaller. If your generator is used as a plugin, you can keep it in a cache in your UI or something to lower the impact of the XMI based serialization.

4) It could, I'll raise the issue on the bugzilla.

If you want to build Acceleo generators to deploy them after that as plugins, I would recommend using Maven 3 and Tycho with the tycho based build.

Regards,

Stephane Begaudeau, Obeo

--
Twitter: @sbegaudeau
Google+: stephane.begaudeau
Blog: http://stephanebegaudeau.tumblr.com
Acceleo Documentation: http://docs.obeonetwork.com/acceleo
Re: [Acceleo] PDE, Ant build and Acceleo(Compiler) [message #720898 is a reply to message #720881] Wed, 31 August 2011 13:02 Go to previous message
Brice Pajot is currently offline Brice PajotFriend
Messages: 4
Registered: June 2011
Junior Member
Hi Stephane,

Thanks for the quick reply.

Quote:

2) I remember that someone had encountered an uri with a "@dot" before, I don't remember how the problem appeared but if I recall correctly it was coming from "${target.folder}" which contained this "@dot". Do you have the line "outputFolder=${target.folder}" below the sourceFolder one?.

Yes, that's still me. I could see that this problem is solved in the last build of Acceleo. That's however not the origin of my new problems (this problem resulted in a missing EMTL file in the built plugin, this error being stated literally in the produced exception).

@dot is a "special" location used in PDE build. But the problem seems not as so related to @dot as the fact that an extra segment is included inside the dependency location URI (I could reproduce a similar behavior with something else than "@dot" by launching a PDE Ant build in an instance of Eclipse).
Maybe the problem is related to the fact that ${target.folder} is specified (by pde) to:
${PLUGINS_BUILD_DIR}/plugin_dir/@dot/
and not:
${PLUGINS_BUILD_DIR}/plugin_dir/
In fact, I'm not an expert in using PDE, so I maybe miss some configuration magic option...

3) Thanks for the advice.

Quote:

If you want to build Acceleo generators to deploy them after that as plugins, I would recommend using Maven 3 and Tycho with the tycho based build.

Right. It seems nice! It's been a while that I wanted to look at this direction. Maybe it's time to make the switch.

Regards,

Brice Pajot.
Previous Topic:[Acceleo]
Next Topic:[JET] invoke a startTemplate (ie a template which use other templates) from Java?
Goto Forum:
  


Current Time: Sat Apr 20 03:10:09 GMT 2024

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

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

Back to the top