Split :launcher into :launcher, :launcherBootstrap and :launcherStartupin order to isolate Java 6 stuffLet split launcher projects code be shipped in a fat jarfor backwards compatibilitySigned-off-by: Paul Merlin <email@example.com>
Simplify time handling internally and for build scans (#2857)* Don't make TimeProvider Serializable.This isn't safe and generally doesn't make sense.* Extract and promote the concept of a build timer.This was previously not well defined and being overlaid with the concept of when a user/tool requested something, which is not always the same thing.* Pare down the deprecated org.gradle.util.Clock down to the minimum required.Internal usage is replaced by a `getStartTime()` directly on BuildRequestContext.What is left is only kept for backwards compatibility with scans.* Rename TimeProvider to Clock.* Move BuildExecutionTimer out of baseServices into core, and into a better package.* Remove unused.* Simplify the time package by merging types.* Prevent the client's build started timestamp from being later than when the provider received the build request.* Provide a dedicated mechanism for conveying the build start time to build scans.* Consolidate the ways of formatting durations.
Split out `Timer` from `EventTimer`- `Timer` has no wall-clock time, and only measure relative/elapsed time- `EventTimer` (nee `Clock`) has a wall-clock start time, plus an elapsed time measure.- Removed the need for wall-clock time in CountdownTimer- Renamed `org.gradle.internal.time.Clock` -> `DefaultEventTimer`Renamed Clock -> EventTimer
Moved `Clock` and `TimeProvider` into a separate packageThis commit reverts recent changes to the API of`org.gradle.util.Clock`, and instead deprecates the existing typereplacing with a new internal type. This was done because the`ExtractDslMetaDataTask` uses this type for timing, and external plugins may have copied this pattern.`org.gradle.util.Clock` is now deprecated.