[GRADLE-2429] A script to search upward for a gradlew to use Created: 09/Aug/12  Updated: 24/Jan/17  Resolved: 24/Jan/17

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

Type: New Feature
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Duplicate Votes: 8

Attachments: File grad    
Issue Links:
Related
Related to GRADLE-1378 Make gradlew more convenient to use Resolved

 Description   

Using gradlew is nice for a lot of reasons, but it somewhat forces you to run things from the command line at the top project level only or use ../../gradlew depending upon where in the subproject tree one is.

How about if there were scripts called gradlew and gradlew.bat that shipped with gradle in the bin directory (so they'd be picked up along the path if a gradle instance were added to someone's path) and they simply attempt to walk up the current directory structure looking for a gradlew/gradlew.bat file.

Below are some scripts that do just that - whether they are well written is a separate issue Not sure if the windows script works in XP, but it definitely works in Vista and above.

*Nix

#!/bin/bash

FOUND=0
CURR_PATH="$PWD"
REAL_GRADLEW="$CURR_PATH/gradlew"

if [ -x "$REAL_GRADLEW" ]
then
FOUND=1
else
while [ "$CURR_PATH" != "/" ]
do
CURR_PATH=$(dirname "$CURR_PATH")
REAL_GRADLEW="$CURR_PATH/gradlew"

if [ -x "$REAL_GRADLEW" ]
then
FOUND=1
break
fi
done
fi

if [ $FOUND -eq 1 ]
then
$REAL_GRADLEW "$@"
else
echo "Unable to find gradlew file upwards in filesystem"
fi

exit 0

Windows

@echo off
setlocal enabledelayedexpansion
set CURR_PATH=%cd%

set REAL_GRADLEW=%CURR_PATH%\gradlew.bat

if exist %REAL_GRADLEW% (
goto :found
)

:while1
call :getdir "%CURR_PATH%"

set REAL_GRADLEW=!CURR_PATH!\gradlew.bat

if exist !REAL_GRADLEW! (
goto :found
)

if "%CURR_PATH:~-1%" == ":" (
goto :notfound
)
goto :while1

:notfound
echo Unable to find gradlew.bat file upwards in filesystem
goto :goodbye

:found
call !REAL_GRADLEW! %*

:goodbye
endlocal
goto :EOF

:getdir
set "CURR_PATH=%~dp1"
set "CURR_PATH=%CURR_PATH:~0,-1%"


 Comments   
Comment by Vasily Karyaev [ 17/Nov/12 ]

Agree, this is a good idea.

Currently we have the following problem (apart from the one specified by the reporter).
Suppose, Gradle version X is installed on the computed, and the gradle wrapper is configured to use version Y.
Depending on which command the user types (gradle or gradlew), the build results may be different. It is actually very easy to forget about typing the extra 'w' character.

Why wouldn't the regular gradle command work the same as the gradle wrapper? I mean, it checks the version specified in build.gradle, downloads the corresponding jar and finally runs the build with the appropriate Gradle version?

Comment by Adam Murdoch [ 18/Nov/12 ]

@Vasily, the plan is to make the gradle and gradlew commands work the same way. We'll probably do this as a couple of steps so that it happens in a relatively backwards-compatible way.

Comment by Joern Huxhorn [ 05/Dec/12 ]

I use this file instead and put it into my PATH as 'grad'. In contrast to the suggested scripts in this issue, this script uses 'gradle' as a fallback if no 'gradlew' was found. The original author is credited in the comments.

Comment by Douglas Borg [ 13/Dec/12 ]

I took a slightly different approach with my script. It can be run from any subdirectory and runs the nearest build.gradle file with the nearest gradlew, falling back to system's gradle if it is not found.

Check out:

https://gist.github.com/4278116

It is based off of the work of Spencer Allain and Chris Beams.

EDIT:

The little script above has turned into a full-blown project @ http://gdub.rocks.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Joern Huxhorn [ 15/Nov/16 ]

This should still be addressed.

Comment by Eric Wendelin [ 24/Jan/17 ]

I agree this is still a good idea. Moving to https://github.com/gradle/gradle/issues/1250

Generated at Wed Jun 30 12:21:41 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.