On Mon, 3 Aug 2026 15:05:26 GMT, Anirvan Sarkar <[email protected]> wrote:
> This makes OpenJFX build properties visible to every Gradle build on the > machine. > In particular, generically named project defined properties such as JDK_HOME, > CONF, INCREMENTAL, and LINT could conflict with unrelated projects or plugins. > > It also prevents developers from keeping OpenJFX only Gradle settings scoped > to this repository, for example: These are valid concerns. > Is there a reason we cannot continue to support a project local, gitignored > `gradle.properties` instead? As explained above, it is required for project configuration such as the toolchain and build properties, e.g.,: org.gradle.caching=true org.gradle.parallel=true org.gradle.configuration-cache=true Having this file gitignored means we can't improve the build (we're stuck with Gradle 2 or 3). It is a committed file in every project I've seen (I can make a list if it helps). Figuratively, the current setup "hijacks" the file. What we can do is add an uncommitted `local.properties` instead with user properties. It'll be read during configuration and replace the current user-specified `gradle.properties` (`JDK_HOME`, `CONF`, `INCREMENTAL`). This is also what's being done in some repos. The `org.gradle*` properties that are required before configuration time (like the deamon switch) can be passed as command flags. For example, the daemon is very useful when developing, but can be disabled for CI/CD, so this is a good option to have on be default and turned off in the CI/CD script (note that OpenJFX [builds without config flags](https://github.com/openjdk/jfx/blob/f8e39e78b742534bb37a097d5c7e34b687e62c24/.github/workflows/submit.yml#L139)). A `GRADLE_OPTS` env var can aggregate them if it helps. Also, git allows locally untracked files if the user really doesn't want the out-of-the-box one, but I don't think it's a good option. It boils down to what the purpose of `gradle.properties` here is. If it's part of the build, like the `build.gradle` and `settings.gradle` files are (and it usually is), then it needs to contain the build configuration that matches the capabilities of these files. If it's a user-configuration, then the user needs to know what can be turned on. For example, making the build file support parallel execution will do nothing until the user "figures out" they need to create a `gradle.properties` locally that enables it. This is a rather terrible user experience, especially for features that have been mainstay for many years now. I'd like to know which gradle settings users want to change and why. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2240#issuecomment-5172866010
