Community
Participate
Working Groups
Build Identifier: 3.6 I've created a maven project for acceleo compilation and acceleo model to text generation. Every time I open a .mtl, a message appear. I think that it's useless (you know that a mtl file need acceleo project nature to compile), and stops Eclipse loading until I click on the OK button. Reproducible: Always Steps to Reproduce: 1. create an ant task or a maven module containing acceleo compiler and generator class (or simply remove acceleo nature to an Acceleo project). 2. Open an mtl file and you'll see the warning.
> I think that it's useless (you know that a mtl file need acceleo project nature > to compile) I think it's a bit more subtle than that, we don't know for sure if a file with the "mtl" extension is an Acceleo template file. So if you want to open that file with the Acceleo Editor (it could be anything) we won't launch our builder (to compile the file) unless we are sure it's an Acceleo file. If we considered that a file with the "mtl" extension is one of our file with or without the Acceleo nature and that we should build it anyway, we would have to take care of lots of problems (MTL is, for example, the extension of "alias material files" in the popular 3D modelling tool Autodesk). When Eclipse starts, it builds all the opened projects. Our builder would create warnings and error markers on every single MTL files in the workspace (even in project that don't have the Acceleo nature and that are not in any way linked to Acceleo) because they don't respect our syntax. We would also create EMTL file in their build folders (compiled MTL files). And people would come here on the bugzilla to say "why are you touching our files to mark them with errors when they don't have the Acceleo nature ?". Nature are here to determine whether or not your builder should take care of that project. If you are opening a MTL file with the Acceleo editor, we need to build it (to put error markers in the editor, to use autocompletion, etc.) and we consider at that point that the user may be trying to use this MTL file has an Acceleo file but we can't be sure, the user could be opening an "alias material file" in Eclipse with the wrong editor, we can't suddenly say "you've open this file with our editor, now your project has our nature and we are going to build all your files in that project with our builder whether you like it or not and if they don't respect our syntax we will put error markers on all of them and create compiled files in your build folder etc". We can't take the decision to build all MTL files in the workspace without the user's consent (the user should have created an Acceleo Project) and we can't say "now this is an Acceleo project" just because the user opened once a file with the MTL extension with our editor. It's even a bit more complicated, because the user may not know that our plugin is installed. For example, if you install the EEF plugin, which needs Acceleo to work, it will install Acceleo too and the regular user may not see it and suddenly all his MTL files turn red and errors appear everywhere... There could be performance issue with having our builder on top of their MTL file builder. We can't take the user by surprise with a critical behavior like that. It's an interesting user interaction problem and I can tell you there is no perfect solution with this but I'm pretty sure (because of the reason that I gave you) that we won't change our behavior unless you have a better solution. For us, if someone want to use our editor on a MTL file, the user should say "ok guys, you can build it because it's inside an Acceleo project". Stephane Begaudeau, Obeo
Can you add a "don't show messages again for this project" checkbox ?
(In reply to comment #2) > Can you add a "don't show messages again for this project" checkbox ? If we had a system like this, we would have a problem. We would have to store that the user doesn't want to see the error message again somewhere. It would end by having to create a file in the project, or something in the metadata folder of the workspace (which is doable but for a such small issue, I have doubts). It's completely possible but I don't think that this bug needs a correction at all, here's why: The message appears if you open the MTL file with our editor and our editor can't work without the builder, which can't work without the Acceleo nature, and we can't put the Acceleo nature without the user's consent (as I explained it in my first message). If you want our editor, you need the Acceleo nature. Sure you can have (I think) very basic thinks like the syntax coloring but that's about it, no support for errors, warnings, autocompletion, code generation, search, refactoring, etc. I won't list all the UI components that needs our builder but the point is that our UI has dependencies with our builder which needs the Acceleo nature. And having the editor without the builder would but almost all feature expect maybe syntax coloring and I don't see why we would support an editor like that. In fact, I would take the problem on the other side, why do you want that project not to have the Acceleo nature ? If you are manipulating (Acceleo) MTL files in it, you will need that file to be build to access most of the features of the editor and therefor you need the Acceleo nature. I fail to see any problem with having the Acceleo nature on a project in which you are manipulating Acceleo files. And if you don't want those file to be build (for any reason) by our builder, you can desactivate the automatic build in the project menu (Project -> Build automatically). You can also create another project with the Acceleo nature to put those files and then add a dependency from your first project to the second one to access its content.
Hi again! The reason why I don't wan't acceleo nature is that Acceleo plugin and M2eclipse project nature are incompatible. You'll understand that I can't disable Maven nature :S. In addition, my projects are compiled with Hudson CI. So I made some Maven archetypes that include Acceleo templates, and a Uml diagram. During Maven generate-sources phase, the Acceleo templates are compiles and then, during the pre-compile phase, model to text is called too, it generates my model classes and associated unit tests (that are ran during the phase test. With this methodology, templates, sources code and diagrams are synchronized each time I compile(via Eclipse or Hudson CI) my project, and in addition I'm sure that all goes right ;). What do you think about this methodo? Are you interested to have some Maven Archetypes in your portfolio (I'm actually porting them from Acceleo 2 to 3)? Regards, Charlie
(In reply to comment #4) > Hi again! > > The reason why I don't wan't acceleo nature is that Acceleo plugin and > M2eclipse project nature are incompatible. Hi again, That part is very interesting. Do you have a precise problem with the Acceleo and M2eclipse ? Because if there is something we can do to solve that part of the problem, we would be interested.
Hi Charlie, (In reply to comment #0) > Every time I open a .mtl, a message appear. > I think that it's useless (you know that a mtl file need acceleo project nature > to compile), and stops Eclipse loading until I click on the OK button. Maybe for you, but the standard user or a newcomer wouldn't know; and it's also quite easy to copy/paste an mtl file in a new project while forgetting that this "new project" must have the Acceleo nature. We won't remove this dialog, that's a given. Nevertheless, we could be a little less "noisy". From the next integration build onward, this dialog will only be shown once per launch of Eclipse. (i.e : you launch your Eclipse and open an mtl file out of an Acceleo project, the dialog is displayed. It will never be displayed again until you close and relaunch Eclipse.) (In reply to comment #4) > The reason why I don't wan't acceleo nature is that Acceleo plugin and > M2eclipse project nature are incompatible. I second Stephane on that, could you elaborate on the incompatibility? Is it something we could fix?
Hi again, Acceleo nature forces compiler to be in 1.5 or 1.6 mode, Maven default uses 1.4. I configured maven on 1.6 compiler, there is no problem anymore. So it's just a trivial problem, we just have to configure Acceleo Maven module with at least 1.5 compiler (or waiting fully 1.5 maven 3 release). Tested on 3.5 eclipse, I'll test 3.6 tonight. I'll also try to import new maven project in eclipse with Acceleo preconfigured .project, .settings files in order to see the results. The ideal is that I create my project using maven archetype (mvn archetype:generate), that generates skeleton, dependency resolution, default class diagram and Acceleo module containing the mtl templates with maven + Acceleo nature). Then I import the project in eclipse (as a Maven project), modify the class diagram (sometimes the templates if they don't fit exactly with my needs) and run maven compilation that performs M2T. Finally TADAAAAAA!, got my background modules completed with domain objects and working with my database plus my Dto's ready for the view and unit tested. Just have to code my data-processing services and the view. If this works perfectly (leave me 2 or 3 weeks to investigate), I will give you an example plus an Acceleo maven plugin that will perform a standalone mtl compilation. See you soon, Charlie
I see ... but even if maven asks for Java 1.4 you still cannot use Acceleo without Java 1.5 anyway :). There isn't anything for us to do on this ^^. I've reduced the frequency of the "Acceleo nature required" popup, I'll consider this particular bug fixed and close the issue. As for a standalone compilation + maven example, we're all for it :).
Thank you! You'll have some news from me soon ;)
That part is very interesting. Do you have a precise problem with the Acceleo and M2eclipse? Yes, I can't import Acceleo/Maven project (a project with both maven nature and Acceleo Nature)
