From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

The `gradle.startParameters` is mutable to some extend but it should be treated as immutable once the build starts. The mutability comes from the fact that launching a build somewhat uses `StartParameters` as input. Once the build starts, it should be treated as immutable (build starts == initialization/configuration phase).

:point_up: That is my general rule of thumb.

yeah, same. but that just makes me want to repeat: there's a missing feature here

What Daniel said :thumbsup: It should have been immutable from the start :face_with_rolling_eyes:

By the time you can mutate `StartParameters` the decision to use the configuration cache has already been made. IOW it’s too late.

a task which write to the user home gradle properties should be feasible by checking the git email or something so for example 

maybe gradle can check local properties too for this feature 

or even better those properties could be set in the settings file so every dev can set it in a flexible way 

Is there any reason those properties are passed via gradle project properties and not via a dsl in the settings?

too late in the build to adjust that behavior, I'd imagine

a special block similar to the plugins block in the settings file should be ideal 

I talked with <@URQ797WRW> about a "similar" problem which would be resolved with another phase.

When a plugin conditionally applies other plugins based on a configuration in the extension, it doesn't generate the accessors and you can't even access to the extension if you don't do that after the configured extension block.

A phase with a custom block which can be read by Gradle so it can generate the dummy project after checking it would solve that.

This use case for the settings file should be similar, a block that Gradle should read ahead

Or simply the desparately missing `gradle-local.properties` possibility: <https://github.com/gradle/gradle/issues/12283>

yes that is exactly the kind of thing I was thinking of, Vampire

Then bring up more uservoice.
Gradle guys think it would be more confusing and not helping, while it imho is an essential possibility.
I sometimes even make manual namespacing for properties, so that I can use `x` in the project `gradle.properties` or on the command line, but `project-a.x` or `project-b.x` in the `&lt;GRADLE_USER_HOME&gt;/gradle.properties` as I want different values for different builds.
I think the only way to get it is to gather enough user-pressure so they add the possibility eventually.