Solving that would be nice. What I don't like with the second solution is the clutter it creates in the project directories.

Wouldn't the first solution also provide the solution for the second problem?

How would the alias approach look like? Would be a relative path, like: ../gradlew? That might lead to issues if you have multiple gradle wrapper builds on the machine with different structures.

What do you mean with installing gradlew separately? Make it a 'normal' command? This could solve all our problems I think. The only issue are possible wrapper incompatibilities. The project specific wrapper script could offer an install functionality.

One thing would alleviate the inconvenient current way to build out of subprojects with the wrapper. If we had tab completion on the command line it would be very easy to trigger partial builds from root.

We tried solving this by writing a script available from all sub projects. The script locates the gradlew script in the directory tree and runs it. The script is run from CygWin and we encountered a path problem. The -Dorg.gradle.wrapper.properties argument is transformed to a absolute path by gradlew and passed to GradleWrapper.java. This results in a java.io.FileNotFoundException: \cygdrive\c\path\to\gradle.wrapper.properties.

We solved this by adding the following to gradlew :

if $cygwin ; then
  WRAPPER_PROPERTIES=`cygpath --dos "$WRAPPER_PROPERTIES"`
fi

The solution using an alias will run into the same problem.

Found a better solution... Since the WRAPPER_PROPERTIES variable might contain file paths it should be treated as JAVA_HOME and CLASSPATH. I suggest adding a line to reformat paths in WRAPPER_PROPERTIES:

# For Cygwin, switch paths to Windows format before running java
if $cygwin ; then
    JAVA_HOME=`cygpath --path --mixed "$JAVA_HOME"`
    CLASSPATH=`cygpath --path --mixed "$CLASSPATH"`
    WRAPPER_PROPERTIES=`cygpath --path --mixed "$WRAPPER_PROPERTIES"` ### Add this line

I think something to make gradlew more convenient would be welcomed by many. There is a script called find-gradle written by Chris Beams that works quite well in making gradlew more convenient. I logged a ticket requesting the script be contributed back to Gradle and he seems to be on board. Would there be consideration in accepting this enhancement?

I'm a big fan (and user) of Chris' script, but the last consent from the dev team was to wait until we have a more widely applicable solution. Probably this means waiting for the native Gradle client.

Thanks for the response Peter. That is a little disappointing they would like to wait since the script would probably be a bit faster to integrate than waiting for the native Gradle client (I could be wrong on this). Hopefully this discussion has at least given a little more exposure to the script so that others can install it themselves and enjoy its benefits. Thanks again for the prompt follow up.

Solving this problem does not need to wait for a native Gradle client. Implementation-wise, we don't need to do much more than add find-gradle and a corresponding find-gradle.bat to the Gradle distribution. And tweak the implementation so it is in Java and reuses the existing 'find the root directory' logic that the wrapper and tooling API both use.

We'll do this at some point - it's just a matter of priorities, particularly given there is a simple workaround.

If anyone is interested in helping to implement this, I've added some details to a 'contribute' idea: http://forums.gradle.org/gradle/topics/make_the_gradle_wrapper_more_convenient_to_use_from_the_command_line

We would love to see this as a contribution from the community, as this feature is currently not high on our list of priorities (unfortunately), but it would make quite a difference to the usefulness of Gradle on the command-line.

At my company we've created a nice workaround for this (based on the find-gradle implementation), but we haven't externalized it yet. I'm trying to get more momentum to get some of our plugins out into the community, and I'll see about pushing this one...

Hi, I added a comment with a few questions about this feature on the forums: http://forums.gradle.org/gradle/topics/make_the_gradle_wrapper_more_convenient_to_use_from_the_command_line, you might want to take a peek and write what you think about it or bash me ;d

I am keen to work on that since it is a problema I have.
Before, I would like my suggestion to be approved :

• Introduce a new property 'org.gradle.preferWrapper', false by default
• If true, executing the command 'gradle' will actually execute the WrapperExecuter
• Introduce a new command 'gradlew' which is exactly the same as executing 'gradle -Porg.gradle.preferWrapper=true'

What do you think?

The benefit of having a variable to handle that is to be able to configure that per project or per environment.

@Thibault, why do you want to configure this per project or per environment?

@Adam
Per project : I want the developers to use the wrapper by default so when they do 'gradle' it actually favors the wrapper. I want to do that because a lot of them absolutely don't care about how the build is working and for some reasons have gradle installed and never do './gradlew' but 'gradle'. I know that my solution is not going to solve this problem until they upgrade gradle but at least if they upgrade gradle (which I can ask them to do), they will always execute the wrapper. I think it is an important feature to be able to say "gradle wrapper is the default way to build the project".

Per environment :
Option 1 : As the build guy, I know exactly when I want to use the wrapper and when I don't. So I configure "org.gradle.preferWrapper=false" for my environment and then I am free to do either 'gradle' or 'gradlew' depending on my needs.
Option 2 : I am often forking projects and If the wrapper is in place, I want to use it. So I configure "org.gradle.preferWrapper=true" for my environment. Anyway, the only time I need to really use the gradle command line is when I want to do a wrapper, which happens not that often...

If no one configure the property, gradle will behave exactly the same as in previous version, except that now you have the gradlew command.

I just feel like my solution is useful, simple to understand, configurable and not really hard to implement.

Ok. Let's give the property a different name, one which describes that you're overriding the declared Gradle version for this build. I wouldn't put the word 'wrapper' in the property name.

Given this property is supported by the `gradle` command, I wouldn't bother with a new `gradlew` command. If someone wants this kind of thing, they can alias `gradlew=gradle -Dorg.gradle.whatever-its-called=true`.

I'm really looking forward to this change. Should really improve the usability of the wrapper.

I've written a small shell script and placed it into /usr/local/bin/gradle:

#!/bin/sh
D=$(pwd)
G="gradlew"
while [ ! -x "$D/$G" -a "$D" != "/" ]; do
    D=$(dirname $D)
done
if [ ! -x "$D/$G" ]; then
    echo "No Gradle found in current or parent directories!"
    exit 1
fi
echo "Run Gradle $D/$G ..."
"$D/$G" $@

The script searches for the Gradle Wrapper in the current directory and its parent directories and executes it. Maybe it's useful for someone else, too.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

The issue is now tracked via https://github.com/gradle/gradle/issues/1368.