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
