Community
Participate
Working Groups
Created attachment 191200 [details] A patch to fix getOutputFilePath and getPackageName We are willing to use Acceleo for a project that is in a subdirectory of our workspace (in a Maven module to be more precise). We are getting a null pointer exception (stack trace follows). The problem seems to be in the AcceleoProject.getOutputFilePath(...) and AcceleoProject.getPackageName(...) methods which tries to compare the source file's absolute full path (for instance /testproject/innerproject/src/main/java/generate.mtl) to the source folders of the project (/innerproject/src/main/java/) without any success.
I have tried to apply your patch and after launching all our Junit tests, we have 252 NullPointerExceptions because "project.getRawLocation()" seems to return null most of the time. I have changed all the "getRawLocation()" to "getFullPath()" but I haven't committed the patch yet. Do you still have the stack trace of the problem ? Can you identify the steps to reproduce your problem with a simple example ? You are saying that your project look like this "/testproject/innerproject/src/main/java/generate.mtl", but which project has the Acceleo nature ? only the inner project ? or do you just have the testproject with the Acceleo nature and the inner project is just the root source folder of all your Acceleo modules ?
(In reply to comment #1) > I have tried to apply your patch and after launching all our Junit tests, we > have 252 NullPointerExceptions because "project.getRawLocation()" seems to > return null most of the time. I have changed all the "getRawLocation()" to > "getFullPath()" but I haven't committed the patch yet. I tested it with getFullPath() but it did not work. I had NullPointers when not using getRawLocation... Do you run your tests in headless ? > Do you still have the stack trace of the problem ? Can you identify the steps > to reproduce your problem with a simple example ? 1) Create an empty "General" project. 2) Create an "Acceleo" project without using the default location and place it inside the previously created project. 3) Go in the MTL file the wizard created. Type a <space> anywhere and save the editor. You may try it by using a Maven project and a Maven module project but this is my guess that you don't support projects with funky location at all. For instance, I usually checkout as project complete modules from SCM and then uses the "Import existing project into workspace" to import the individual projects. Thus the same MTL file is in two different location in the workspace at the same time, and this looses the file path algorithm you use. > You are saying that your project look like this > "/testproject/innerproject/src/main/java/generate.mtl", but which project has > the Acceleo nature ? only the inner project ? or do you just have the > testproject with the Acceleo nature and the inner project is just the root > source folder of all your Acceleo modules ? The inner project has the Acceleo nature. testproject (Maven POM project) - innerproject (Maven Module project + Java, Acceleo and I guess PDE nature) If you give me a patch I may rollback my changes and apply your patch to try. But for sure using getFullPath() instead of getRawLocation works for half the cases, because the fileAcceleo variable is rooted in the virtual Workspace/innerproject directory as if the innerproject project was located in the workspace directly. I had to debug the getOutputFilePath() to figure out what was going on.
> I tested it with getFullPath() but it did not work. I had NullPointers when > using getRawLocation... Do you run your tests in headless ? No the unit tests are not launched in headless. It produce a NPE with a simple Acceleo project too. The problem seems to come from "project.getDescription().getLocation()" which is called from by "Project#getRawLocation()" because the javadoc of "getLocation()" on the IProjectDescription states that: "Returns the local file system location for the described project. The path will be either an absolute file system path, or a relative path whose first segment is the name of a workspace path variable. null is returned if the default location should be used. This method will return null if this project is not located in the local file system." And I think that this part: "null is returned if the default location should be used" is the problem. With regular project at their default location it returns null to indicate that we should use the default location (not very developer friendly...). Anyway, know that I have a good description of how you are finding this problem, I have been able to reproduce it. I changed the patch a bit, could you try it and tell me if it's working for you. It worked for me, the compilation of an Acceleo module was successful, even if I've found another bug somewhere else in the mean time so I won't commit it right now. I don't even know if we are responsible for this other bug, so I'll have to take some time to investigate. I'll get back to this bug tomorrow morning.
Created attachment 191695 [details] Acceleo subproject patch Patch.
(In reply to comment #3) > And I think that this part: "null is returned if the default location should be > used" is the problem. With regular project at their default location it returns > null to indicate that we should use the default location (not very developer > friendly...). I see. Obviously I do not read the javadocs often enough :) > Anyway, know that I have a good description of how you are finding this > problem, I have been able to reproduce it. I changed the patch a bit, could you > try it and tell me if it's working for you. It worked for me, the compilation > of an Acceleo module was successful, even if I've found another bug somewhere > else in the mean time so I won't commit it right now. I don't even know if we > are responsible for this other bug, so I'll have to take some time to > investigate. I'll get back to this bug tomorrow morning. Great :p I confirm it works correctly here too. Thank you very much Stephane!
The fix has been contributed on HEAD, it will be available in Acceleo 3.1M7 next months. In the mean time, if you find any other problem with this kind of project, don't hesitate to create a new bug entry. By the way, the bug that I had witnessed was indeed coming from us (a refresh problem at the creation of the Acceleo subproject) and it has also been fixed.
