Current Dir

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Current Dir

hans_d
Administrator
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?

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator

On Sep 11, 2008, at 12:15 PM, 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?

This Maven behavior described above is just the behavior of the  
surefire plugin (for executing tests).  It is supposed to do the  
following:

From: http://jira.codehaus.org/browse/SUREFIRE-416

"To solve this, we're going to set user.dir to be ${basedir} when  
forking; when not forking we'll temporarily change the global system  
properties, and finally change them back. (This should be part of a  
more general test of systemProperties when not forking.)"

I'm a bit sceptical of the solution taken by the surefire plugin:

See: http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4117557

"I've just come across this problem - code I've been working on uses  
setProperty("user.dir", /xyz") and works as expected most of the time  
because most Files are explicitly converted to absolute before native  
filesystem accesses. However, some aren't, leading to occasional  
unexpected behaviour.

I'm simply astounded by the slow and weak response to this simple  
problem, and it's low priority. Whatever, the technical justification  
for not supporting chDir, the inconsistent behaviour in File and In/
OutputStreamFile should be made consistent, or at least documented in  
the API. Furthermore, fixing it will cause behaviour change  
inexisting code - probably need a flag somewhere to specifiy whether  
paths are resolved against jvm working directory, or user.dir, or  
sometimes one and sometimes the other as is the current behaviour."

So I think we should not do change the user.dir by default as Java  
does not guarantee correct behavior. The user's who need the 'Maven'  
behavior can set those properties in the build scripts. I gonna give  
this a try now.

- Hans

>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Stefan Groschupf
In reply to this post by hans_d
This definitly does not smell from my point of view, since it is very  
common for tests to read and write into project relative paths.
Actually if you deal with files relative is the only way....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101tec Inc., Menlo Park, California
web:  http://www.101tec.com
blog: http://www.find23.net



On Sep 11, 2008, at 3:15 AM, 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?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Stefan Groschupf
In reply to this post by hans_d
In general I think it makes a lot of sense to stay as close as  
possible with how maven works.
Changing such behavior would be a big barrier for people want to move  
to gradle.
Stefan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101tec Inc., Menlo Park, California
web:  http://www.101tec.com
blog: http://www.find23.net



On Sep 11, 2008, at 4:10 AM, Hans Dockter wrote:

>
> On Sep 11, 2008, at 12:15 PM, 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?
>
> This Maven behavior described above is just the behavior of the  
> surefire plugin (for executing tests).  It is supposed to do the  
> following:
>
> From: http://jira.codehaus.org/browse/SUREFIRE-416
>
> "To solve this, we're going to set user.dir to be ${basedir} when  
> forking; when not forking we'll temporarily change the global system  
> properties, and finally change them back. (This should be part of a  
> more general test of systemProperties when not forking.)"
>
> I'm a bit sceptical of the solution taken by the surefire plugin:
>
> See: http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4117557
>
> "I've just come across this problem - code I've been working on uses  
> setProperty("user.dir", /xyz") and works as expected most of the  
> time because most Files are explicitly converted to absolute before  
> native filesystem accesses. However, some aren't, leading to  
> occasional unexpected behaviour.
>
> I'm simply astounded by the slow and weak response to this simple  
> problem, and it's low priority. Whatever, the technical  
> justification for not supporting chDir, the inconsistent behaviour  
> in File and In/OutputStreamFile should be made consistent, or at  
> least documented in the API. Furthermore, fixing it will cause  
> behaviour change inexisting code - probably need a flag somewhere to  
> specifiy whether paths are resolved against jvm working directory,  
> or user.dir, or sometimes one and sometimes the other as is the  
> current behaviour."
>
> So I think we should not do change the user.dir by default as Java  
> does not guarantee correct behavior. The user's who need the 'Maven'  
> behavior can set those properties in the build scripts. I gonna give  
> this a try now.
>
> - Hans
>
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project lead
>> http://www.gradle.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Adam Murdoch-2
In reply to this post by hans_d


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.

One thing that would be reasonable to do, is to set the working dir when
the tests are run in forked mode. In the case of test-ng we could also
inject a parameter which is set to the project dir. 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.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Stefan Groschupf

On Sep 11, 2008, at 7:00 PM, Stefan Groschupf wrote:

> This definitly does not smell from my point of view, since it is  
> very common for tests to read and write into project relative paths.
> Actually if you deal with files relative is the only way....

There are other, better ways to deal with this.

You can put your test files in the resources folder and say:

File testFile = new File(getClass().getResource
("someresource").getPath());

If for some reason you also need to execute your tests from a jar  
(for example because you use your read only integration tests also  
for monitoring) you can extract the test file as a stream and write  
it to a file in a temporary folder.

I think this is much better than depending on the value of the  
current dir.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Stefan Groschupf
Hi Stefan,

On Sep 11, 2008, at 7:03 PM, Stefan Groschupf wrote:

> In general I think it makes a lot of sense to stay as close as  
> possible with how maven works.
> Changing such behavior would be a big barrier for people want to  
> move to gradle.

We want to make it as easy as possible to migrate builds from Maven.  
But we won't sacrifice correctness and expressiveness for this.

- For example Maven puts its transitive dependencies into the compile  
classpath. I think this is very bad (see discussion in the user's  
guide12.1.2). Gradle behaves differently by default.
- Another example is the way Maven deals with the current dir. If you  
execute tests in forked mode the Maven behavior (setting the working  
dir of the forked JVM to the subproject dir) makes sense and we will  
do the same as a default. But for non forked execution Maven is  
setting the user.dir property. The Sun people strongly recommend not  
to do this. The result of this setting the user.dir is that sometimes  
the relative paths are resolved correctly and sometimes not. This is  
for example the case with the current multi-project build I'm working  
on. Therefore Gradle will not adopt this behavior.

In one of our next user's guide there will be a chapter dedicated to  
Maven migration. I think if we mention all the relevant issues and  
explain why we do certain things different, people will be happy with  
it. After all, they have a reason why they migrate to Gradle. :)

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Adam Murdoch-2

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


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator

On Sep 11, 2008, at 11:07 PM, Hans Dockter wrote:

>>
>> 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)
>  }

I have filed a Jira: http://jira.codehaus.org/browse/GRADLE-216

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Stefan Groschupf
In reply to this post by hans_d
I'm not sure if I clearly understand what you proposing. But I'm very  
concerned here!
It is ok if a open source project is self-confident but you will win  
zero users if a project is arrogant. Let your users decide it it make  
sense to execute from a project root. (All tools I know do this, eg  
eclipse, intellij etc)
Relaying on the project dir structure is a very common use case for  
loading test data, resources etc.
To be honest if we need to change all tests that are relay on a  
project structure to be able to use gradle, I would prefer a other  
build tool.
If a new users tests gradle and no test working any more, than I'm  
very sure he will turn around very quick.



~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
101tec Inc., Menlo Park, California
web:  http://www.101tec.com
blog: http://www.find23.net



On Sep 11, 2008, at 1:54 PM, Hans Dockter wrote:

> Hi Stefan,
>
> On Sep 11, 2008, at 7:03 PM, Stefan Groschupf wrote:
>
>> In general I think it makes a lot of sense to stay as close as  
>> possible with how maven works.
>> Changing such behavior would be a big barrier for people want to  
>> move to gradle.
>
> We want to make it as easy as possible to migrate builds from Maven.  
> But we won't sacrifice correctness and expressiveness for this.
>
> - For example Maven puts its transitive dependencies into the  
> compile classpath. I think this is very bad (see discussion in the  
> user's guide12.1.2). Gradle behaves differently by default.
> - Another example is the way Maven deals with the current dir. If  
> you execute tests in forked mode the Maven behavior (setting the  
> working dir of the forked JVM to the subproject dir) makes sense and  
> we will do the same as a default. But for non forked execution Maven  
> is setting the user.dir property. The Sun people strongly recommend  
> not to do this. The result of this setting the user.dir is that  
> sometimes the relative paths are resolved correctly and sometimes  
> not. This is for example the case with the current multi-project  
> build I'm working on. Therefore Gradle will not adopt this behavior.
>
> In one of our next user's guide there will be a chapter dedicated to  
> Maven migration. I think if we mention all the relevant issues and  
> explain why we do certain things different, people will be happy  
> with it. After all, they have a reason why they migrate to Gradle. :)
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Adam Murdoch-2


Stefan Groschupf wrote:

> I'm not sure if I clearly understand what you proposing. But I'm very
> concerned here!
> It is ok if a open source project is self-confident but you will win
> zero users if a project is arrogant. Let your users decide it it make
> sense to execute from a project root. (All tools I know do this, eg
> eclipse, intellij etc)
> Relaying on the project dir structure is a very common use case for
> loading test data, resources etc.
> To be honest if we need to change all tests that are relay on a
> project structure to be able to use gradle, I would prefer a other
> build tool.
> If a new users tests gradle and no test working any more, than I'm
> very sure he will turn around very quick.
>

I don't think its quite as bad as you image. To get the maven behaviour
you can either:

- run your tests in fork mode:

test.options.fork()

- set the user.dir property before you run the tests:

test.doFirst { System.setProperty('user.dir', projectDir.absolutePath }


We could even make fork mode the default for tests.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Stefan Groschupf
> We could even make fork mode the default for tests.


If maven is doing fork test as default I would do that. At least until  
you converted all maven users to gradle users.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

Adam Murdoch-2


Stefan Groschupf wrote:
>> We could even make fork mode the default for tests.
>
>
> If maven is doing fork test as default I would do that. At least until
> you converted all maven users to gradle users.
>

Perhaps another option is to add a Maven compatibility plugin, which
tweaks the java plugin to be more maven-like. That way, we can provide
some of these 'questionable' behaviours without baking it into the core.


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Stefan Groschupf

On Sep 12, 2008, at 12:31 AM, Stefan Groschupf wrote:

> I'm not sure if I clearly understand what you proposing. But I'm  
> very concerned here!
> It is ok if a open source project is self-confident but you will  
> win zero users if a project is arrogant. Let your users decide it  
> it make sense to execute from a project root. (All tools I know do  
> this, eg eclipse, intellij etc)
> Relaying on the project dir structure is a very common use case for  
> loading test data, resources etc.
> To be honest if we need to change all tests that are relay on a  
> project structure to be able to use gradle, I would prefer a other  
> build tool.
> If a new users tests gradle and no test working any more, than I'm  
> very sure he will turn around very quick.

Stefan, if you had read my former email in detail you would have  
learned that I propose to have the same behavior as Maven for running  
tests in forked mode (which is the default for Maven).

- Hans

>
>> Hi Stefan,
>>
>> On Sep 11, 2008, at 7:03 PM, Stefan Groschupf wrote:
>>
>>> In general I think it makes a lot of sense to stay as close as  
>>> possible with how maven works.
>>> Changing such behavior would be a big barrier for people want to  
>>> move to gradle.
>>
>> We want to make it as easy as possible to migrate builds from  
>> Maven. But we won't sacrifice correctness and expressiveness for  
>> this.
>>
>> - For example Maven puts its transitive dependencies into the  
>> compile classpath. I think this is very bad (see discussion in the  
>> user's guide12.1.2). Gradle behaves differently by default.
>> - Another example is the way Maven deals with the current dir. If  
>> you execute tests in forked mode the Maven behavior (setting the  
>> working dir of the forked JVM to the subproject dir) makes sense  
>> and we will do the same as a default. But for non forked execution  
>> Maven is setting the user.dir property. The Sun people strongly  
>> recommend not to do this. The result of this setting the user.dir  
>> is that sometimes the relative paths are resolved correctly and  
>> sometimes not. This is for example the case with the current multi-
>> project build I'm working on. Therefore Gradle will not adopt this  
>> behavior.
>>
>> In one of our next user's guide there will be a chapter dedicated  
>> to Maven migration. I think if we mention all the relevant issues  
>> and explain why we do certain things different, people will be  
>> happy with it. After all, they have a reason why they migrate to  
>> Gradle. :)
>>
>> - Hans
>>
>> --
>> Hans Dockter
>> Gradle Project lead
>> http://www.gradle.org
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Adam Murdoch-2

On Sep 12, 2008, at 3:24 AM, Adam Murdoch wrote:

>
>
> Stefan Groschupf wrote:
>>> We could even make fork mode the default for tests.
>>
>>
>> If maven is doing fork test as default I would do that. At least  
>> until you converted all maven users to gradle users.
>>
>
> Perhaps another option is to add a Maven compatibility plugin,  
> which tweaks the java plugin to be more maven-like. That way, we  
> can provide some of these 'questionable' behaviours without baking  
> it into the core.

Very good idea.

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Adam Murdoch-2

On Sep 12, 2008, at 1:58 AM, Adam Murdoch wrote:

>
>
> Stefan Groschupf wrote:
>> I'm not sure if I clearly understand what you proposing. But I'm  
>> very concerned here!
>> It is ok if a open source project is self-confident but you will  
>> win zero users if a project is arrogant. Let your users decide it  
>> it make sense to execute from a project root. (All tools I know do  
>> this, eg eclipse, intellij etc)
>> Relaying on the project dir structure is a very common use case  
>> for loading test data, resources etc.
>> To be honest if we need to change all tests that are relay on a  
>> project structure to be able to use gradle, I would prefer a other  
>> build tool.
>> If a new users tests gradle and no test working any more, than I'm  
>> very sure he will turn around very quick.
>>
>
> I don't think its quite as bad as you image. To get the maven  
> behaviour you can either:
>
> - run your tests in fork mode:
>
> test.options.fork()
>
> - set the user.dir property before you run the tests:
>
> test.doFirst { System.setProperty('user.dir',  
> projectDir.absolutePath }
>
>
> We could even make fork mode the default for tests.

I have just realized that this is not the case right now. I think we  
definitely should make fork the default. First of all not for Maven  
compatibility but for providing a clean sandbox to the tests. In  
particular if the tests work with system properties. Should we have  
as the default fork mode once or perTest? perTest is the more  
reliable one. I'm not sure if the performance penalty is significant  
for Java tests. If your tests are written in Groovy this is  
significant (therefore the Gradle build uses the once mode).

I have filed a Jira: http://jira.codehaus.org/browse/GRADLE-217

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Current Dir

hans_d
Administrator
In reply to this post by Adam Murdoch-2

On Sep 12, 2008, at 1:58 AM, Adam Murdoch wrote:

>
>
> Stefan Groschupf wrote:
>> I'm not sure if I clearly understand what you proposing. But I'm  
>> very concerned here!
>> It is ok if a open source project is self-confident but you will  
>> win zero users if a project is arrogant. Let your users decide it  
>> it make sense to execute from a project root. (All tools I know do  
>> this, eg eclipse, intellij etc)
>> Relaying on the project dir structure is a very common use case  
>> for loading test data, resources etc.
>> To be honest if we need to change all tests that are relay on a  
>> project structure to be able to use gradle, I would prefer a other  
>> build tool.
>> If a new users tests gradle and no test working any more, than I'm  
>> very sure he will turn around very quick.
>>
>
> I don't think its quite as bad as you image. To get the maven  
> behaviour you can either:
>
> - run your tests in fork mode:
>
> test.options.fork()
>
> - set the user.dir property before you run the tests:
>
> test.doFirst { System.setProperty('user.dir',  
> projectDir.absolutePath }

This would be good to have in the Maven Compatibility plugin.

This plugin would also include the transitive dependencies of the  
compile configuration in the compile classpath.

I have filed a Jira for this Maven compatibility plugin:

http://jira.codehaus.org/browse/GRADLE-218

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email