[GRADLE-366] Gradle should make it easy to determine the full path to the build.gradle file Created: 22/Jan/09  Updated: 04/Jan/13  Resolved: 28/Feb/09

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 0.6

Type: New Feature
Reporter: Jon Cox Assignee: Hans Dockter
Resolution: Fixed Votes: 0

Issue Links:
Superceded by GRADLE-368 The Gradle -b option should specify a... Resolved


Sometimes, it's very useful for scripts to know their own directory; however,
determining the name of a script file in a portable way in Groovy is currently
royal pain in the neck. For details on Groovy's issues here, see:

For this & other reasons, I'd love it if Gradle would have some
extra 'build' object properties such as:

build.properties.buildScriptDirName == cannonicalized path to dir containing build.gradle file (or whatever it's named)
build.properties.buildScriptFileName == leaf-name of build script itself (typically build.gradle)

Eventually, I hope that Groovy's "script.name" property gets sorted out on all platforms
and is equal to the cannonicalized path to the script. However that's not quite good enough
for gradle for two reasons

[1] Often the directory is wanted, and "script.name" is the
fullpath to the script – not separating the name from the path.
Call me lazy, but I'd like my build environment to spare me
from hassles like this.

[2] The ugly-but-backward-compatible hack I came up with on Linux:
new File(getClass().protectionDomain.codeSource.location.path).parent
could end up giving you the path to a .gradle/cache directory, rather than
your build.gradle file's directory, depending if you've got caching on or not.
Madness! Thus this info really should be a built-in to gradle. I think that
'build.properties.<..some-name...>' is the logical place for it.

For more details on Groovy's current problems with script.name, see:

Comment by Hans Dockter [ 26/Jan/09 ]

We provide this already:


Does this solve your issue?

Comment by Jon Cox [ 26/Jan/09 ]

Yes it does – thanks.

The string "projectDir" appears once in italics in table 10.3,
and once in a pseudcode-ish variable name in 16.3.3
(bottom of page 51). In each case I'm guessing I read it
as a conceptual reference, not an an actual field within the
'project' object.

It's good to maintain a distinction between the
user manual and the reference manual, but currently
the user manual could probably do with a bit more
enumeration of what's available in projects & other objects
(plus a few more pointers to the reference manual).
I may have still missed something like "projectDir",
but something like that may have helped.

Comment by Jon Cox [ 26/Jan/09 ]

Wait a second.... I don't think projectDir actually works the way I'd expect.
Suppose we created the file /tmp/xxx.gradle to look like this:

    println "user dir:    " + System.getProperty("user.dir")
    println "project dir: " + this.projectDir
    println "build file:  " + this.build.startParameter.buildFileName

Now let's 'cd' to '/' and run the command line:

   %     gradle -q  -b /tmp/xxx.gradle   foobar

What we get out is:

user dir:    /
project dir: /
build file:  /tmp/xxx.gradle

Notice that the user executed the command from '/' so Groovy sets
the system property "user.dir" to "/", as you'd expect.

The next line differs from what I'd expect to see:
the project dir (this.projectDir) is also set to "/", rather than "/tmp

Is the current behavior of "this.projectDir" a bug?
Should it be coming back with "/tmp" or am I misunderstanding
it's purpose? If so, what does come back with /tmp ?

The final line is not quite what I would have expected
(I thought I'd see "xxx.gradle", not "/tmp/xxx.gradle"),
but it seems like you could still say "that's reasonable".. maybe.
The thing that make me say maybe is that sometimes buildFileName
reports the file name as a relative path, not an absolute one.
Also, it would be nicer if the value always gave an absolute
path if it were going to go that route... as things stand, it gives
you a relative path if you're in the same dir & call the script
using a relative name

    % cd  /tmp
    %  gradle  -q -b  xxx.gradle foobar 

Think about what you'd like Gradle to do if someone said something
a bit crazy looking like:

  % cd /
  %  gradle  -q -b /tmp/../tmp/xxx.gradle   foobar 

Currently, it emits:

user dir:    /
project dir: /
build file:  /tmp/../tmp/xxx.gradle

That seems a bit wonky – if the build file is going to be reported as
an absolute path under certain circumstances, and a relative path
under others, then I'd expect that the path be normalized to "/tmp/xxx.gradle"
not left at "/tmp/../tmp/xxx.gradle"

If you have a chance, see also: http://jira.codehaus.org/browse/GROOVY-1642

Comment by Hans Dockter [ 26/Jan/09 ]

Gradle has two command line options related to this, -p and -b.


gradle -q  -p /tmp - b xxx.gradle foobar

should lead to the output.

user dir:    /
project dir: /tmp
build file: xxx.gradle

The -b property was intended to specify the build file name, not the path. It was assumed that the build file lives in the project root dir. So my first intention was to see your example as a Gradle bug in that it accepts an illegal option argument. But on the other hand why not allowing to specify a build file path separate from the project dir. Then we have two other bugs. The -b property should be described as 'assign build file name, and the start parameter property should be called buildFile. And the latter should not be of type String but of type File and would be normalized at construction time.

I have filed: http://jira.codehaus.org/browse/GRADLE-368

This will also solve Gradle-366.

Comment by Adam Murdoch [ 28/Feb/09 ]

I've added Project.buildFile, which returns a File whose path is the canonical path of the build file. I think this should solve the problem.

Generated at Wed Jun 30 11:28:19 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.