search

grails / grails-maven

67 stars 52 forks source link

Set working directory for tests in multi-module scenario #54

Open selera opened 10 years ago

selera commented 10 years ago

In a hierarchical multi-module project situation, when tests are executed on leaf-node modules, the current working directory is not being set to the directory of the leaf-node module being built.

This is the way maven/surefire works, and it seems to me that this maven plugin should do this for us too.

That way test cases can read/write files relative to the module that they belong to.

Any objections to me submitting a patch for this?

bmcguire commented 10 years ago

I'm all for a fix for this issue. It has caused me issues on more then one occasion and agree it is the way it should work.

selera commented 10 years ago

From a cursory inspection of the grails maven plugin (and some debug logging to verify) it seems the plugin itself is doing the right thing. In AbstractGrailsMojo.createExecutionContext() its passing the maven project base.dir (the leaf-node directory) as the base directory for the execution context of the grails launcher. Hmmm.

selera commented 10 years ago

Interesting. When running in Fork=true mode we don't encounter the issue. In fork=false our working directory for grails test cases is the root of the multi-module maven hierarchy (bad behaviour). In fork=true, the working directory is the project directory of the module being built (good behaviour).

Configure fork=true in the configuration block of the grails-maven-plugin in your pom.xml

fork=false builds faster though...

bmcguire commented 10 years ago

@selera Thanks for the tip I will check that out and see how that works. But I believe your original point still holds true that there is a bug. It should not matter if fork is set to true or false, you should still get the same results. Also there are time when I need/like to have fork set to false, specifically when running unit test in IntelliJ it shows the test results in the IDE directly and the it also makes it possible for the IDE to collect code coverage.

graemerocher commented 10 years ago

There does seem to be a bug yes, although fork=false is not recommended for multi-module builds because it runs the Grails process within the Maven process which leads to memory issues

bmcguire commented 10 years ago

@graemerocher Even though running with fork=false leads to memory issues it is still needed in certain cases as I mentioned in comments above. If there is a patch for this I would really like to see it get incorporated to the project.