Thanks to you all! I had been having the same issue. I wonder if something as simple as putting a circuit breaker [props_version] property in `gradle.properties` could be helpful? For changes that could indicate the need to regenerate gradle.properties, the "magic" property could be incremented. That would simplify detection of potential error cases, and allow to print more meaningful warning/instructions.
Instructions/failure message could be something like: "[something has changed]. You might want to consider re-generating your `gradle.properties` file (and re-applying any custom modifications). to ignore this warning, you can manually update [props_version] property in your current `gradle.properties` file". It'd be a little hacky; but it would be effective in proactively putting this information in front of users who need it. IMO it'd be ok to fail the first run if gradle.properties hadn't yet been generated. The static check could fail the first run, but with a more transparent message; e.g.: "prerequisite `gradle.properties` was successfully generated, but is not available for this run. Simply re-run the last command; the newly-generated `gradle.properties` file will be picked up on subsequent runs". The potential confusion I guess would arise from the fact that there are tasks that _don't_ require a pre-generated `gradle.properties` file, and and these would fail unnecessarily? Michael On Thu, Apr 7, 2022 at 2:11 AM Dawid Weiss <[email protected]> wrote: > > Hi Mike, > > Thanks, Mike. So I removed gradle.properties (I never edited anything >> in there), and re-run, and I can see that I now have >> > > This file is generated and contains some defaults optimized for a local > machine. Yes, it may change from time to time and these changes will not be > picked up automatically. > > >> which seems as if it ought to fix, but I got the same error -- OH -- >> but not the second time??! wacky, but (crossing fingers) I hope it > > will stay fixed now >> > > Here's why. The first time you run gradle after you remove the properties > file, the build scripts see the file is not there and regenerate the > defaults. However, the gradle instance doesn't automatically pick up the > just-generated defaults (it can't, they are JVM-settings) so any subsequent > task may fail as if that file wasn't present at all. A subsequent run will > pick up the new settings from the gradle.properties file and that's why it > worked for you. > > Perhaps it should be better explained here - if you can find a wording > that works, please modify it: > https://github.com/apache/lucene/blob/main/help/localSettings.txt > > In theory we could interrupt (stop) gradle execution if gradle.properties > hasn't been generated yet but in practice this would cause more confusion > than help. I don't think there is a clean way around it. > > Dawid >
