Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 339996

Summary: Acceleo Builder not supporting projects in subdirectories
Product: [Modeling] Acceleo Reporter: Didier Villevalois <ptitjes>
Component: CoreAssignee: Project Inbox <acceleo-inbox>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: mariot.chauvin, stephane.begaudeau
Version: 3.0.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard: maven
Attachments:
Description Flags
A patch to fix getOutputFilePath and getPackageName
none
Acceleo subproject patch none

Description Didier Villevalois CLA 2011-03-15 06:43:32 EDT
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.
Comment 1 Stephane Begaudeau CLA 2011-03-22 04:29:21 EDT
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 ?
Comment 2 Didier Villevalois CLA 2011-03-22 05:00:51 EDT
(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.
Comment 3 Stephane Begaudeau CLA 2011-03-22 12:28:15 EDT
> 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.
Comment 4 Stephane Begaudeau CLA 2011-03-22 12:28:41 EDT
Created attachment 191695 [details]
Acceleo subproject patch

Patch.
Comment 5 Didier Villevalois CLA 2011-03-22 13:31:37 EDT
(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!
Comment 6 Stephane Begaudeau CLA 2011-03-23 06:34:41 EDT
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.