Skip to content
This repository was archived by the owner on Jan 26, 2021. It is now read-only.

gw: always execute from same dir that gradle or gradlew would (#22)#27

Open
javabrett wants to merge 2 commits intogdubw:masterfrom
javabrett:same-dir
Open

gw: always execute from same dir that gradle or gradlew would (#22)#27
javabrett wants to merge 2 commits intogdubw:masterfrom
javabrett:same-dir

Conversation

@javabrett
Copy link
Copy Markdown

@javabrett javabrett commented Nov 28, 2017

This PR addresses #22:

  • Commit 1
    • adds a gradle build for gw itself, just as a convenient way of running some script-tests.
    • adds a Travis build for running those tests.
    • adds test which run both before and after a gradle-wrapper is installed, testing gradle and gradlew wrapping behaviour. The test fails - it is testing that the correct subproject task is executed in a subproject without a build.gradle, and checks the behaviour is the same for all four of gradle, gradlew, gw->gradle, gw->gradlew.
  • Commit 2 fixes by removing the cd to the closest ancestor dir with a build.gradle.

In a properly constructed multi-project Gradle project this should make no difference - Gradle doesn't require you to run -b ../../......../build.gradle and gw should not assume you want to run from the rootProject, because neither gradle nor gradlew do.

Test framework uses a bash script to exercise gw.  It assumes that at least "gradle" is
installed and that "gradlew" is not installed in a parent path to the project build.

The tests should be run once before and once after a gradle wrapper has been installed.
Refer to .travis.yml for details.

As of this commit the test will fail.
gdubw#22.

gw should match the behaviour of both "gradle" and "gradlew" without surprises.
Prior to this change, if there is a subproject without its own build.gradle, gw
will change-up to some ancestor project which does have a build.gradle. This results
in different behaviour to "gradle" and "gradlew" when executed from the same
location.

This change removes the cd.  A proper gradle multi-project structure will
still allow the resulting gradle runtime to locate the root project and its
build.gradle.
@yeshvantbhavnasi
Copy link
Copy Markdown

Seems like this is already changed.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants