Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Revert "Message for incubating execution mode is not shown if the mode is explicitly configured (e.g."

This reverts commit 7fa641429cdd04a00f8bdf3f6364909fbd32a5ae.

It didn't work for the daemon execution and I wasn't happy with the implementation, too.

(cherry picked from commit d21b4bc)

  1. … 13 more files in changeset.
Message for incubating execution mode is not shown if the mode is explicitly configured (e.g.

1. The use case is that organisations may roll out incubating mode to all projects and don't want to confuse the end users (e.g. fear about the features that may be perceived incomplete, confusing request for feedback in the incubating message). So, if the incubating mode is explicitly configured in the gradle properties, we assume that the user knows what he is doing and need not be reminded about the incubating nature of the feature. (while writing this commit message it just occurred to me that this should be in the spec)

2. The implementation is not quite pretty, looking for suggestions on how to improve it.

  1. … 13 more files in changeset.
REVIEW-1198 Refactored the commandline / properties conversion in order to tidy up the internals.

  1. … 25 more files in changeset.
Added gradle property 'org.gradle.parallel' for parallel execution.

1. I decided to only add org.gradle.parallel for now (avoid parallel.threads). It's because it feels awkward to configure exact number of threads in the - Gradle should figure out the optimal number for the user. Supporting both 'org.gradle.parallel' and 'org.gradle.parallel.threads' also means that we need to code some rules for the scenario when the user specifies both options (e.g. some combinations are mutually exclusive).

2. Added startParameter.isParallelThreadCountConfigured() method. This is a bit awkward but that was the simplest reasonable solution I came up with. (btw. We need to make StartParameter an interface). There's some complexity around the start parameter & gradle properties processing:

a. First we need to parse / convert the command line arguments because they contain information needed for gradle properties parsing (e.g. search upwards, directory, user home, etc.)

b. then we need to pull data from gradle properties and update the start parameter accordingly. However, the command line arguments should generally win over the gradle properties. So gradle properties can only update the start parameter *if* start parameter was not explicitly configured with given property.

3. The StartParameter.newInstance() method seems to be incorrect (the source and target instances share some collections). Should I fix it?

I'm open to discussion how to solve above better.

  1. … 5 more files in changeset.
Configure on demand. Some refactorings & reworking of the coverage.

Now the BuildActionsFactoryTest is not influenced by file present in local dev environment. Moved some coverage to more relevant spot (e.g. the properties precedence order moved to GradlePropertiesConfigurerTest).

  1. … 4 more files in changeset.
--configure-on-demand. Fixed problems with the tooling api. Now the new command line option is correctly handled.

  1. … 4 more files in changeset.
Configuration on demand now available at the command line.

1. Introduced --configure-on-demand command line option.

2. Reworked the DaemonParameters. New class GradleProperties deals with configuring various gradle properties from sources like and system properties.

    • -0
    • +182
    • -0
    • +41
  1. … 12 more files in changeset.
added org.gradle.debug system property to facilitate debugging of (daemon) JVM (similar to test.debug)

  1. … 1 more file in changeset.
Moving Jvm to org.gradle.internal.jvm and SettingProperties to org.gradle.internal - Attention: This affects the next update of the gradle wrapper as we use JVM in our build scripts.

  1. … 72 more files in changeset.
Moved some recent jvm related code into the 'internal' package because it is internal.

  1. … 7 more files in changeset.
Tighten up the process of deciding when to fork a new JVM for non-daemon build - Always fork a new JVM if immutable JVM arguments have been explicitly specified. - Never fork a JVM if mutable JVM arguments have been specified, just set the system properties.

  1. … 3 more files in changeset.
Non-daemon builds now honour jvm args set via - Added 'CurrentProcess' (needs a better name) that determines if the currently running process can support the specified build parameters - More integration tests for builds forking to support jvm args

    • -0
    • +82
    • -18
    • +3
  1. … 4 more files in changeset.
Fixed a typo.

  1. … 2 more files in changeset.
Refactoring. Cleaned up some code around daemon server parameters. It was a bit awkward that the jvm opts were configured after creating the DaemonMain instance. Now the DaemonMain is configured by an type that explicitly informs what are the daemon server configuration parameters.

    • -1
    • +8
    • -0
    • +45
  1. … 5 more files in changeset.
Refactoring. Fixed some class dependencies to make the design clearer. The DaemonMain/ForegroundDaemonMain does not depend on DaemonParameters any more. It's clearer to see what is the configuration of the daemon server without actually going through the DaemonParameters that contain various defaulting and parsing logic. Still some cleanup with the daemon's startupJvmOptions is pending.

    • -0
    • +203
    • -0
    • +31
    • -0
    • +47
  1. … 17 more files in changeset.