Adam Murdoch schrieb:
On 28/01/10 7:08 AM, René Gröschke wrote:
hi there,
I'm running my builds by calling gradle in my project directory and
use the -b flag to point to my build file which is stored at a
directory, where all my build files are stored. I detected, that
relative paths e.g.
addArtifactPattern(file('../ThirdParty').absolutePath ...
is now interpreted to be relative to my build file. Is this behaviour
intended?
Yes. As John mentioned, file() is interpreted relative to the project
directory. And for a single project build, the project directory
defaults to the directory containing the build file. To change this,
you need to use a settings.gradle. You could tweak this with an init
script, as well.
In the Gradle 0.10 release, we plan on merging the settings.gradle
into the build file. This will mean, for example, the build file will
be able to specify where the project directory is. I think this would
solve your problem, as each of your build files would specify their
project directory. This would mean file() and everything which
implicitly uses file (ie pretty much any method which takes a string
path) would resolve against the correct directory. And this would
happen regardless of how Gradle is invoked.
IMHO if I call gradle from a specific working directory, this should
be the starting point for relative paths.
This can be dangerous, as then for a build to work correctly, Gradle
must always be launched with a particular working directory. For
example, this forces things like IDE plugins, GUIs, CI servers to
always fork the Gradle process, rather than using it in embedded mode.
It also makes working with multiple builds from the command-line more
difficult, as it involves a bunch of 'cd' commands between builds,
which would be otherwise unnecessary.
I think a better option is that file paths are resolved against a
fixed location that is independent of how Gradle is launched - that
is, the project directory.
When you follow the convention for project layout (ie build file in
the project directory), then the working directory == the project
directory, and it works as you expect. We could potentially change the
convention to work better in your case. Why do you want all your build
files in one directory?
Another annoying behaviour I noticed, is that the directory where the
I store my build file is polluted with a .gradle directory. I think
this should also be stored/generated in my working directory,
shouldn't it?
This is related to the above. The .gradle directory is created in the
project directory of the root project of a build. It's there for the
same reason that file() uses the project directory, that is, because
it is a fixed location that is independent of how Gradle is launched.
We've discussed the option of moving this stuff to live under
~/.gradle somewhere (which is also a fixed location). Having it live
in the project directory makes garbage collection easy, but having it
live under ~/.gradle is probably a better behaviour overall.
I'm administrating the macports ports for some groovy related projects
like groovy, grails, griffon, gant and gradle. We try to build all our
ports from sources, so I use ./gradlew in the macports script to build
gradle. Since installing a port via macports is done by "sudo port
install ..." the ~/.gradle directory is created as su if it not yet
exists. I would like to avoid this by using a temporary directory for
.gradle while gradle installation. Any Ideas for that?
regards,
rené
--
------------------------------------
Rene Groeschke
[email protected]
http://www.breskeby.com
------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
