The only difference between running your local /usr/bin/gradle vs gradlew
should potentially be the gradle version. The purpose of gradlew is to
allow a project to force a particular version of gradle. Maintaining
backcompat in build.gradle files for features gradle has changed or removed
is difficult, and to gradlew is a convenient way that a developer doesn't
even need to think about the gradle version, or ever upgrading. The wrapper
script upgrades when the project changes the wrapper script.

> Is there anyway to make our 'build.gradle' files "fail" if someone does
*NOT* use our './gradlew'

It might be possible by looking at the gradle distribution location and
failing if it is not in `$GRADLE_HOME/wrappers`.

But as far as the importance, if a user really doesn't want to use it, I'm
not sure we should force them to. It is just more work on them to upgrade
gradle as necessary (note that upgrading the wrapper would not force them
to upgrade, only a change in the build files that broke with the version of
gradle they were using would).

> I have 'gradle' aliased to 'gw' ( aka: 'gdub" =>
https://github.com/gdubw/gdub )

I've never heard of `gdub`, but to me the alias is backwards. It seems the
purpose is to fallback to /usr/bin/gradle if a gradlew file does not exist.
FWIW, I alias `gw` to my own script which automatically finds `gradlew` by
traversing up from my current directory. This is because I prefer to cd
into directories to work on them in a terminal, so I don't pass the project
directory to gradle, yet I must run `gradlew` at the root of the project.

To summarize, gradlew is a helper for both developers and projects to
easily move along with new gradle releases with very little work from both
sides. But to gradle there is no difference, it is only a wrapper to
download and run a version of gradle. Once invoked, it is the same as
running /usr/bin/gradle (ie looks at your local gradle properties, project
properties, etc).

Hope that helps.

On Wed, Sep 2, 2020 at 10:33 AM Chris Hostetter <hossman_luc...@fucit.org>
wrote:

>
> 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
>
>

Reply via email to