Spinning this off of a side comment Dawid made in a jira...
: ... Hoss -- you absolutely should use the provided wrapper script, not
: your system's gradle.
: {code}
: hossman@slate:~/lucene/dev/solr/solr-ref-guide [j11] [master] $ gradle
buildSite -PsolrGuideVersion=9.0
: {code}
: This is important as those startup shell scripts in the repo have
: additional stuff added on top of them compared to stock gradle.
I have 'gradle' aliased to 'gw' ( aka: 'gdub" =>
https://github.com/gdubw/gdub ) ... which i thought was a recomendation I
had seen from Dawid but i'm not finidng it now, so i honestly have no idea
where I leaned about it.
IIUC this is "doing the right thing" as far as running gradlew if it
exists -- but now i'm not so sure? ... in the output/code block Dawid
replied to above, the very first line of output was 'gw' saying...
>> Using gradle at '/home/hossman/lucene/dev/gradlew' to run buildfile
>> '/home/hossman/lucene/dev/solr/solr-ref-guide/build.gradle':
...but is that "enough" ? or is there context/options that may not be
getting picked up unless i explicitly run './gradlew -p
solr/solr-ref-guide ... ' from the root level checkout?
As a novice gradle user these questions put me in the mind of a "new dev"
coming to lucene, and I thought "Let's check the README!" ... where I see
instructions to use './gradlew' mentioned (and pointers to './gradlew
help') but nothing that really jumps out at me at screams "It's really
important to use './gradlew' not 'gradle' (or 'gw') and here's why: ..."
-- should there be?
Lastly: Is there anyway to make our 'build.gradle' files "fail" if someone
does *NOT* use our './gradlew' (ie: maybe set a special property in
gradlew that our build.gradle file can look for and fail if unset?
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
