I don't want to blow this discussion out of proportion so I'll try to make it quick...
> There is convention for this :) The convention is to commit your > gradle.properties and that is what holds your project config. It's widely > done and promoted by the Gradle team. I disagree with this statement and base my opinion on both my experience and what's written in [1]. The gradle.properties file is for configuring gradle (and the build's system properties), not for configuring project properties and project-related behavior. Even the API reflects this distinction (gradle environment vs. the Settings object vs. eventual project properties and their inheritance). I'd argue that the current setup abuses gradle properties for things that could as well be defined elsewhere; ideally as normal project properties (however loaded or declared) where they'd be nicely propagated to subprojects. But it's cosmetics, fine. > The daemon is not controlled by us, it's controlled by you and what you put > in your global file. Exactly. But the versioned gradle.properties has: org.gradle.daemon=false If I'd like to work with Lucene with daemon enabled, I'll have to change this setting globally (in ~/.gradle.properties). This will affect any other Gradle project I have on that machine, which isn't too great. Sure, I can set up an environment variable override or even a command alias but it's not the point -- it's either a global override of this daemon setting or having a dirty checkout. And this somehow doesn't feel right to me. > I would say this: their code to manage this is 1000 times more simple than > the code to do it in randomized testing :) Well, I strive for perfection but am not hesitant to recognize brighter minds (think JUnitBenchmark vs. JMH...). > For something like testFast (or whatever it's called), first it's super > simple code, second, Hmm. Did you push these changes? Which branch is this testFast code on? I committed a few cleanups to jira/SOLR-13452_gradle_7 -- don't know if you saw them. > This is a big build, there is a lot going on. [... ] so I think it's best > that we devote a JIRA to anything that people feel is important in order to > focus an actionable discussion. I think it'd be easier to work collectively on that dedicated gradle branch, cleaning up stuff and introducing small changes there, but if you'd rather have Jira issues or PRs that's up to you -- I asked about this but didn't receive a reply. Dawid [1] https://docs.gradle.org/current/userguide/build_environment.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
