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
