Adam Murdoch schrieb:
On 2/02/10 8:52 AM, René Gröschke wrote:
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?
Not really, other than copying the whole source distribution into a
temp dir and building from there. Or deleting the .gradle dir after
the installation.
There's some things we could do to Gradle to make this work better:
1. Merge the caches so that everything is stored under ~/.gradle.
Then, you can use the -g command-line option to specify where this
should live.
2. Add a command-line option to specify where the $rootDir/.gradle
folder should live
3. Re-add the -C off command-line option and make sure everything that
uses a cache can deal with not having one.
I prefer option 1.
I played a bit with gradlewrapper and detected the GRADLE_USER_HOME
property. I think in my case, the easiest way to avoid ~/.gradle
creation as SU is to set the GRADLE_USER_HOME property to a temp
directory created during the macports installation process and delete it
when build is finished. The overhead this solution brings is that every
third party lib must be downloaded from remote repositories. Maybe i can
check if ~/.gradle already exists before starting the build. This could
avoid duplicate lib downloads.
Thanks so far,
René
Could you add a JIRA issue for this problem, if you need us to do
something to fix it?
--
------------------------------------
Rene Groeschke
[email protected]
http://www.breskeby.com
http://twitter.com/breskeby
------------------------------------
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
