Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

bq. Yes it's an obvious thing and may be a tedious explanation for experienced Java developers... The tradeoff, though, is that the experienced Java developers then don’t have to answer as many questions on the dev list from people new to the ecosystem. I’ll gladly trade some wordiness in a

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

> Oh thanks, was not aware of that. Then I don't understand the discussion > between you and some committers who did not run "gradlew" and used "gradle" > instead. Where was the issue then? I don't think it was a "discussion" as per having an argument - it was more of a "how does this thing

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

Just for a supplement... > Then I don't understand the discussion between you and some committers who did not run "gradlew" and used "gradle" instead. Where was the issue then? I think the original motivation/point of this thread is "how to prevent newdevs (gradle newbies) from using 'gradle',

RE: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

Hi, > > Enforcing version and gradlew vs local shouldn't be difficult. > > We already enforce the version: > https://github.com/dweiss/lucene-solr/blob/master/gradle/validation/check- > environment.gradle#L42-L45 > > If you run a non-wrapper gradle (local) or via gradlew does not matter > as

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

re: txt files .vs. the Wiki. In the end, I came down on keeping text files pure. I’ve come to view it as something of a hierarchy, the less the plain text files reference this web thingy the better. So I’ll change the CWiki page to mention the plain text files and leave it at that… I did make

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

> > remember the goal is to split Lucene and Solr repositories... > > As of 9.0.0 ? :) The build itself - absolutely. When you think about packaging source distributions it'll be a nightmare to distribute with a top-level wrapper, etc. This has to be split into two independent gradle root

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

> Enforcing version and gradlew vs local shouldn't be difficult. We already enforce the version: https://github.com/dweiss/lucene-solr/blob/master/gradle/validation/check-environment.gradle#L42-L45 If you run a non-wrapper gradle (local) or via gradlew does not matter as long as it's the same

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

Enforcing version and gradlew vs local shouldn't be difficult. As you said, Uwe, the version is gettable programmatically, and could be checked in the same check-environment script Dawid already mentioned. Whether or not the gradle wrapper is being used is a little tricker, but the code source for

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

Hi, I was thinking about a check, do build refuses to start when it figures out that Gradle version is not exactly ours or it's stated not from gradlew (I think we have something for checking if gradlew script has all modifications). I think this should be doable? Getting version number of

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

> remember the goal is to split Lucene and Solr repositories... As of 9.0.0 ? :) I found lucene/BUILD.md needs to be refined anyways (it contains information for Solr devs for some reason), so I opened a PR. https://github.com/apache/lucene-solr/pull/1835 Please review it, I'd merge it in the

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

I'd rather move things out of the top-level and into solr/ lucene/ folders - remember the goal is to split Lucene and Solr repositories... Dawid On Sun, Sep 6, 2020 at 2:46 AM Tomoko Uchida wrote: > > For what it's worth, we already have lucene/BUILD.md in the repository: >

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

For what it's worth, we already have lucene/BUILD.md in the repository: https://github.com/apache/lucene-solr/blob/master/lucene/BUILD.md Maybe we can move it to top level folder (and elaborate it if it's needed) ? I'd prefer that build information/tips can be quickly accessed without jumping to

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

> That gets kind of circular and the two can certainly get out of sync... > Right. I personally much prefer editing text files in the repository than wiki pages (and I rarely look at our cwiki, sadly). Dawid

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

> 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

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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 wrote: > I’m using zsh shell with oh-my-zsh and the gradle plugin. It adds an alias

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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

Re: The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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

The "supported" way to run gradle -- was: Re: [jira] [Commented] (LUCENE-9495) Ref Guide gradle buildSite ignores version parameter

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