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 <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 <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] > <mailto:[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 <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] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> >
