On Sep 11, 2008, at 10:26 PM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi,
I have hit upon a current dir issue when porting a Maven build to
Gradle. Maven seems to change the current dir to the sub project
it is actual building. Some test classes in this subproject rely
on this as they use relative paths. Whether this is a design smell
is one question. The other question is if Gradle should also
change the current dir to the project dir of the task it is
executing?
Personally, I think that it is poor form to write builds or tests
that depend on the current directory of the process to be set to
some particular location.
Even if it were a good idea, it is difficult to implement. Lots of
things ignore the 'user.dir' property (FileInputStream for
example), so we'd need native code to do this properly. Or we'd
need to fork a process for each project. Or some bytecode weaving.
Or something equally nasty.
In addition, changing the process' current directory also limits
our options for running things in parallel. The same is true of
setting system properties on a per-project basis.
This was a very spontaneous idea and I agree that it doesn't make
sense. In particular as it does not provide any significant benefit
(and even hides the real current dir).
One thing that would be reasonable to do, is to set the working dir
when the tests are run in forked mode.
That makes sense I think, and is as easy as that:
test {
options.fork(dir: projectDir)
}
In the case of test-ng we could also inject a parameter which is
set to the project dir.
Cool.
Another option would be to provide some way for the tests to
programatically ask gradle for the project dir (and other details
about the project), such as a static method somewhere.
We could add this HelperClass and a property file with the actual
project details to the testRuntime classpath. On the other hand this
would create a coupling between the tests and Gradle one usually
would not want.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
