Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » M2T (model-to-text transformation) » Acceleo : A solution for dependencies to another project with Java launcher
Acceleo : A solution for dependencies to another project with Java launcher [message #1773492] Thu, 28 September 2017 15:26 Go to next message
Mad Vin is currently offline Mad VinFriend
Messages: 35
Registered: September 2013
Member
Hi,

It seems Acceleo is not able to manage imports to mtl files in another Acceleo project when the generation is launched as Java application.

Are there solutions to bypass the problem ?

Adding a symbolic link in your project to the main source folder of the imported project works (the compiler reacts as the imported source code is in the project), but for complex dependencies tree between different Accelo projects, it is a little complicated.

So would you have any idea for another solution ?

Thank you.

Best regards.
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1773504 is a reply to message #1773492] Thu, 28 September 2017 15:56 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5930
Registered: July 2009
Senior Member
Hi

If you are a skilled EMF practitioner you can manipulate the ResourceSet/URIMap in a revision of the auto-generated Acceleo main program to outwit Acceleo's simplistic resolutions.

If this is your only problem and if you keep all your projects as siblings you may succeed with only minor tweaking. Do not use multiple GIT repos so that the files are all over the place.

If you want multiple GIT repos expect major tweaking. You might find /org.eclipse.ocl.pivot/src/org/eclipse/ocl/pivot/internal/resource/StandaloneProjectMap.java helpful.

I had a further URI resolution problem through use of OCL both for tooling and as part of my user models. If you are interested you can study my Acceleo Buzilla reports and my long deleted Acceleo templates in the org.eclipse.ocl.examples.build plugin. For me four years ago with Acceleo 2.3 the solution was to move to Xtend. Perhaps the URI resolution problems have now been fixed.

Regards

Ed Willink
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1773505 is a reply to message #1773504] Thu, 28 September 2017 16:34 Go to previous messageGo to next message
Mad Vin is currently offline Mad VinFriend
Messages: 35
Registered: September 2013
Member
Ok, so you think the problem comes from the URI resolution of the imported mtl files ?

Do you know a link explaining how to proceed, or a simple example ? Because I don't really know what to do with your suggestions.

The fact is that i have an Accelo project named "Common" containing helpers templates and queries useful for several other Acceleo projects. So all these projects must be kept as siblings, and are not all in the same Git repository.
But i can also have more complex dependencies trees between the Acceleo projects, for example : CppGenerator imports Common / PythonGenerator imports Common / DatabaseGenerator imports CppGenerator, PythonGenerator, Common.

Thank you.

Regards.
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1773507 is a reply to message #1773505] Thu, 28 September 2017 17:27 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5930
Registered: July 2009
Senior Member
Hi

The Acceleo editor that creates *.emtl files runs within Eclipse where "platform:" is a virtual location allowing "../../.." navigation between projects. All works fine.

Unfortunately Acceleo templates run standalone and (unlike Eclipse OCL's StandaloneProjectMap) Acceleo does not provide a correspondingly virtual "platform:" emulation. Instead there are some pragmatisms that make simple cases work. That was before GIT came alone and spread the projects throughout the file system. Consequently now with GIT, IMHO the pragmatisms make many cross-project resolutions fail. If you want to try to make it work you probably need to understand how StandaloneProjectMap creates a full "platform:/resource" / "platform:/plugin" emulation or how EcorePlugin.ExtensionProcessor creates a partial emulation. If you are going to do cross-GIT resolution expect to work hard.

Regards

Ed Willink
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1775244 is a reply to message #1773507] Thu, 26 October 2017 16:57 Go to previous messageGo to next message
Mad Vin is currently offline Mad VinFriend
Messages: 35
Registered: September 2013
Member
Hi !

Thank you for your help, but i don't know what and how to do with the StandaloneProjectMap class in an Acceleo project, I've found no example on the Internet.

However, I've found something interesting to fix my problem of dependencies on the Acceleo settings.

To understand more clearly what I'm talking about, here is an easy example of Acceleo projects dependencies :

- 2 Acceleo projects : "generator.utils" and "generator.python"
- "generator.utils" is a project containing only utility queries and templates, that are useful for several kind of generators. So it contains no main template.
- "generator.python" is a project generating python language files from UML models. It depends of the "generator.util" project to be able to import and use the utility queries and templates.
- an Acceleo Configuration is created to configure a generation launcher on a main template of the "generator.python" project

=> If the Acceleo Configuration is configured to use the "Acceleo Plug-in Application" runner, the generation works.
=> If the Acceleo Configuration is configured to use the "Java Application" runner, the generation doesn't work because the dependency to the "generator.utils" project is unknown.

As said previously, the problem comes from the .emtl compiled files of Acceleo modules that reference by default the imported projects, templates and queries like this : "href="platform:/resource/generator.utils/bin/...".

But if you change the "Compilation Path Kind" setting on the "generator.python" project (Properties -> Acceleo Compiler -> Compilation Path Kind) by choosing "Absolute file system paths", the generation with the "Java Application" runner works now, because the links to the imported elements have been modified in the .emtl files like this : "href=../../../../../generator.utils/bin/..."

This solution enables to fix my problem because in my environment, the Acceleo projects must always be at a fixed position one to another. I just hope this setting exists on the old version of Acceleo I use on older projects.

However i have some questions :

1) Why this property in the Acceleo compiler settings says you use "absolute file system paths" while the generated paths are relative ones ? Paths starting by "../../../../../../" are not absolute but relative.
2) Is there a simple way (with an example) to use a property value (from a Java properties file) to replace the "platform:/resource/generator.utils" or "../../../../../../generator.utils" by the value of this property ? During the compilation ? During the execution ? Or else a "dirty" solution is to launch a script making a replaceAll in the .emtl files during the deployment of the jars on the user's PC.

Thank you.

Best regards.
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1775246 is a reply to message #1775244] Thu, 26 October 2017 17:14 Go to previous messageGo to next message
Ed Willink is currently offline Ed WillinkFriend
Messages: 5930
Registered: July 2009
Senior Member
Hi

Unless one of the Obeo guys can be more helpful, the functionality you have is what you have. Do whatever works for you.

Regards

Ed Willink
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1775251 is a reply to message #1775246] Thu, 26 October 2017 19:56 Go to previous messageGo to next message
Mad Vin is currently offline Mad VinFriend
Messages: 35
Registered: September 2013
Member
Ok... do you think he will pass in the area ? :p
I haven't seen him for a moment there...
Re: Acceleo : A solution for dependencies to another project with Java launcher [message #1775648 is a reply to message #1775251] Thu, 02 November 2017 15:21 Go to previous message
Laurent Goubet is currently offline Laurent GoubetFriend
Messages: 1857
Registered: July 2009
Senior Member
Hi,

Sorry for the delay, I had a few computer issues on my end.

What you describe here are limitations with the way Acceleo refrences its imports. As you've discovered the templates need to be references in a way we can "find" them. "platform:/" URIs are something that only exists within eclipse, and the standalone ("java application") launch will thus be unable to resolve such URIs.

You can workaround that by customizing the URIMap of the resource set used by your generator (resourceSet.getURIConverter().getURIMap().put(...)) which would allow you to tell Acceleo where the emtl files really are. You would have to register one mapping for each of the emtl files. The "registerPackages" method of the generated java launcher is a good place to configure these.

Another option would be to hook your own URIConverter in there so that you can replace the "platform:/resource/generator.utils/" URI prefix with your own relative or absolute path dependent on the user platform if you can compute it at runtime. For that, I'd suggest overriding the "createURIConverter" method of the generated java launcher, delegating to the super.createURIConverter() result if eclipse is currently running. This would be the "cleaner" option, but it'll require you to be able to actually compute (or know) the location of your other project on disk.

Laurent Goubet
Obeo
Previous Topic:Generate Code from Ecore metamodel
Next Topic:[Acceleo] Problem with the deleted protected zones
Goto Forum:
  


Current Time: Mon Jun 25 04:46:10 GMT 2018

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

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

Back to the top