Yep; I also use oh-my-zsh with the gradle plugin, and so I simply type "gw"
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Sep 2, 2020 at 3:32 PM Jan Høydahl <[email protected]> wrote: > I’m using zsh shell with oh-my-zsh and the gradle plugin. It adds an alias > "gradle=gradle-or-gradlew» which will automatically select ./gradlew when > it exists. > https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/gradle > I also have gdub/gw and I think I prefer that workflow. > > Jan. > > > 2. sep. 2020 kl. 19:52 skrev Ryan Ernst <[email protected]>: > > 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 <[email protected]> > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
