vi forever! I think my counter-argument is that it’s hard to pack lots of information into a help file and have it be useful. My mental model here is that “gradlew help” should be short enough to give a direction without causing the reader's eyes to glaze over so linking in the Wiki page is something of an organizational tool. Maybe I have a short attention span, but “man curl” makes my head hurt ;)
There’s no problem at all making the Wiki page to tell people about help/* and emphasizing that the very most up-to-date info is there. That gets kind of circular and the two can certainly get out of sync... > On Sep 4, 2020, at 11:22 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: > > > I would rather do the opposite - have that wiki page reference (or link to) > the help pages in the code... Don't get me wrong, but I prefer when it lives > with the code in one repository so that changes can be updated, etc. I know, > I'm old-fashioned. Don't even use md or anything like that. But stuff in > plain text is hard to break. > > D. > > On Fri, Sep 4, 2020 at 3:18 PM Erick Erickson <erickerick...@gmail.com> wrote: > re: “gradle newbie”. Can we reference: > https://cwiki.apache.org/confluence/display/SOLR/Building+Solr+with+Gradle? > > I think it makes sense to put a reference to that in the gradle help file > rather than try to reproduce that info in the text and then have to keep them > coordinated. > > I’m thinking just one additional line like: > > For additional details about using Gradle to build Solr, visit > https://cwiki.apache.org/confluence/display/SOLR/Building+Solr+with+Gradle > > I can take care of that if people think it’s a good idea. > > Erick > > > On Sep 4, 2020, at 5:55 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: > > > >> 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. > > > > I think it might have been Mark Miller's; I'm on Windows and so don't use > > gdub. > > Sorry I raised a false alarm - didn't suspect an alias. :) > > > >>>> 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 > > > > I think this is enough. I don't know gdub but I suspect it just looks > > up the folders tree > > for the wrapper, that's it. > > > >> 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? > > > > Maybe you're right and there should be some kind of "gradle-newbie" > > introduction. I don't think I'm the right person to write it though since > > things > > seem trivial to me that probably aren't in general... > > > > There are two problems with running system-wide gradle: > > > > - gradle versions may differ (and this is a bad thing, sadly); we > > enforce gradle version to be exactly the same as the wrapper's but if > > you're unlucky, your build may not even get to that place and fail > > miserably with some cryptic exceptions... > > - we did add a few utility modifications to gradlew scripts - these > > are helpful to keep things neat and tidy. > > > >> 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? > > > > We already do -- in "check-environment.gradle". Like I said, it may > > happen that your system-wide gradle will simply fail before it has a > > chance to run that snippet. This is the problem. > > > > Dawid > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
