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
