gw executes from project root

[huxi]

gw (the version currently obtained via brew install gdub) always builds all projects of a multi-project build. Below is the script gw was supposed to replace which behaves correctly in that it only builds the current directories project as well as any project it depends on.

#!/bin/bash

# PURPOSE
#
# The Gradle wrapper[1] is a simple and convenient way of making Gradle
# builds self-contained and reproducible. However, in multi-project
# builds, it can be cumbersome to type in relative paths e.g.:
# ./gradlew # when in root
# ../gradlew # when in subdir
#
# This script finds any Gradle wrapper (gradlew) executable in the
# current directory or any directory above it. If none can be found,
# it will fall back to the system-wide installation at $SYSTEM_GRADLE.
#
#
# INSTALLATION
#
#1. Remove GRADLE_HOME/bin from your PATH if it's already present.
#
# $ which gradle # should return empty when finished
#
#2. Symlink find-gradle somewhere on your path as 'gradle', e.g.:
#
# $ ln -s $PWD/find-gradle /usr/local/bin/gradle
#
#
# USAGE
#
# Use exactly like you would a normal Gradle executable. All arguments
# supplied are `exec`d against the gradle(w) executable once found.
#
# $ gradle [options]
#
#
# DEBUGGING
#
# To observe the search for gradlew and to ensure which one is
# ultimately used, invoke the script with Bash's "-x" option. Below you
# can see the directory traversal at work, finally selecting the
# 'gradlew' script one directory up from where 'gradle' was invoked.
#
# $ cd /Work/spring-framework/spring-context
# $ bash -x $(which gradle) --version
# + GRADLEW=/Work/spring-framework/spring-context/gradlew
# + GRADLEW=/Work/spring-framework/gradlew
# + /Work/spring-framework/gradlew --version
#
# ------------------------------------------------------------
# Gradle 1.0-milestone-8-20120112000036+0100
# ------------------------------------------------------------
# ...
#
#
# AUTHOR
#
# Chris Beams (http://twitter.com/cbeams)
#
#
# BUGS
#
# It doesn't look for 'gradlew' in the root directory. Why would you
# want it to? Improvements welcome at http://github.com/cbeams/shell-scripts.
#
# [1] http://gradle.org/docs/current/userguide/gradle_wrapper.html


SYSTEM_GRADLE=/usr/local/bin/gradle

CWD=$PWD
until [ $CWD == / ]; do
GRADLEW=$CWD/gradlew
    if [ -e $GRADLEW ]; then
exec $GRADLEW $@
    fi
CWD=$(dirname $CWD)
done

echo No Gradle wrapper found, using $SYSTEM_GRADLE
exec $SYSTEM_GRADLE $@

[tomdcc]

Yeah, this is unexpected behaviour. If I'm in a sub-project directory ../gradlew tasks runs :project:tasks whereas gw tasks runs :tasks, which is quite different.

[javabrett]

I understand that this behaviour occurs (or at least has the greatest impact) when you run from a project sub-directory that does not container a build.gradle file, but is otherwise considered a subproject. gw is cding to a parent directory until it finds a build.gradle. If the current directory has a build.gradle (either a root project or a subproject) then no difference occurs.

This behaviour does then differ from normal gradlew.

Since gradle and gradlew are perfectly-capable of locating the current root project, I wonder if this feature could be removed - or was there some other value in the cd?

[dantesun]

https://github.com/gdubw/gng/releases/tag/v1.0.2 fixed this issue.