Community
Participate
Working Groups
This is really just a re-re-opening of Bug 335761 and similar bugs, since I have just needed to edit an imported template in order to remove an error in an importing template. Generally, while the Acceleo editor is much much better than a naive editor, the Acceleo editor has a disappointingly large number of incremental bugs that show up whenever a non-trivial development is undertaken. Incremental update of markers is very poor (and slow); for my transformations I generally have at least four 'errors' that only clear on save. Update of markers on save is not always correct. I strongly recommend that one of the development team uses Acceleo to develop a non-trivial (at least two days work) template and just notes all the problems that arise.
Created attachment 214028 [details] Example plugins to demonstrate acceleo editor bugs I agree with Ed. My ultimate goal regarding my recent experiments with Acceleo is to make my colleagues switch from StringTemplate to Acceleo 3. On a real project, Acceleo 3 currently reports 87 errors that I can all remove by null editing and saving each module separately. All these false alarms will significantly hinder my team efforts to learn (an build confidence in) MOFM2T (which is a shame, it is such an improvement over Acceleo 2). Consequently, I cannot realistically trigger the process until the editor stop scaring beginners away ;) I have attached an example that demonstrate some of the issues. I have defined two metamodels "root.metamodel" (for generation root) and "source.metamodel" (for source file). "source.metamodel" itself defines two classes "Implementation" and "Header" that inherits from the class "Root" defined in "root.metamodel". Now, "source.m2t" is an acceleo project with a main module "source.mtl". The first time you create and edit "source.mtl", everything goes fine. But, restart the workspace and edit "source.mtl" again. After a short delay, the editor will claim that it failed to load the source metamodel. The FAQ says to add the source metamodel plugin as a dependency which successfully removed that error. Yet, the editor can no longer recognize attributes that "Header" inherits from "Root". At that point, adding the root metamodel as a dependency and explicitely declaring it in the module did not remove the error. BTW: I am using Acceleo nightly build 3.2.1.v20120402-0438
Hi Michael, First of all, the source metamodel should be added in the dependency tab of the menifest.mf, otherwise it will not work. After adding it, the bug on the feature "name" is visible. This mechanism (one metamodel depending on another one) is supported but it appears that we had a regression. If you have something like this: generator project metamodel A metamodel B The generator depends on the meta-model A and the meta-model B, we are registering both metamodels just as we should but, we were registering them in the order used to explore the dependencies: generator --- depends on --> metamodel A --- depends on --> metamodel B So we are registering metamodel A and then metamodel B but since the metamodel B is not registered, the inherited features in the metamodel A cannot be found. I fixed this with a "Lists.reverse(metamodelsFoundInDependingProjects)" in the builder. You can have a look at the result in this screenshot: https://plus.google.com/u/0/photos/105625286543794908607/albums/5552047126204483729/5731905578160943426 I'll need to add some unit tests for this and I'll mark this issue as resolved once it's done and once a nightly build is available. The fix will be contributed in HEAD and R3_2_maintenance, it will be available in Acceleo 3.2.1 and 3.3.0.
Small additional comment to specify a detail, you should have your dependencies correctly specified between your two meta-model project. The meta-model source requires the meta-model root located in another plugin, yet its manifest.mf does not declare this dependency. Just like source.model depends one root.model or you can specify all your dependencies in the manifest of your generator (in the same logical order source then root). Without this information, it will never work, even if you are in the workspace Acceleo works with Eclipse plug-ins project and the information declared in the manifest is important. I'll add a part about this in the new documentation (not yet contributed in the nightly releases).
(In reply to comment #2) > The fix will be contributed in HEAD and R3_2_maintenance, it will be available > in Acceleo 3.2.1 and 3.3.0. Any chance of 3.1 maintenance given that 3.2 and 3.3 don't build reliably.
(In reply to comment #3) > I'll add a part about this in the new documentation (not > yet contributed in the nightly releases). Please do. Dependency management seems to be a tricky matter: Ecore metamodels, their generated java classes and Acceleo modules can all live in distinct plugins. From your comment, I understand that the metamodel plugin dependency tree has to be specified by the user (i.e. EMF cannot generate it from the ecore loaded resources). Then, it needs to be carried over the children Acceleo plugins. Acceleo documentation could certainly cover the issue better, or at least warn explicitly about it.
> Ecore metamodels, their generated java classes and Acceleo modules can all live > in distinct plugins. From your comment, I understand that the metamodel plugin > dependency tree has to be specified by the user (i.e. EMF cannot generate it > from the ecore loaded resources). Then, it needs to be carried over the > children Acceleo plugins. By default EMF generates the code of the meta-model in the project containing the meta-model so the MANIFEST.MF are generated and thus the dependencies are configured. In your case, you have generated the code in another project (*.model) and everything is configured there. It should not be defined in the generator, you should only referenced there the meta-models that you are directly using (and not their dependencies too). Acceleo can generate those dependencies in the MANIFEST.MF of a newly created Acceleo project if the meta-model as been installed in the Eclipse instance since it is registered by EMF, thanks to the extension point, and we have more information about it this way.
I have installed the latest nightly build and I am currently in the process of fixing my plugins dependencies as per your instructions. So far, most fake errors have vanished. I will post feedback when I am finished (probably by wednesday). BTW, in some legacy ecore files, dependencies are stored as platform URI instead of workspace relative ones. This seems to confuse Acceleo when the URI points to a plugin living in the workspace.
I confirm that the latest nightly build removes almost every fake errors, at least on my project. I still get some transient errors from times to times but I cannot reproduce them reliably. I think that my VCS is causing them: modifying files outside of Eclipse ought to mess up its understanding of the dir state.
Seems mostly fixed from the last comment here and the tests we did with EEF.
