Daniel Lacasse

The focus is on improving the Gradle runner kit and moving away from centralized Gradle fixtures. This is no longer a candidate for 1.2.

We added an experimental flag to do some performance comparison (see https://github.com/gradle-plugins/toolbox/pull/80).

The change we did in #80 is not enough. At least we can now see the network activity in the build scan: However, the query time is about 0.3s on...

Another experimentation for performance: https://github.com/gradle-plugins/toolbox/pull/84

Regardless of what we use there are about .5 seconds just for head check. I think we should try to differ the checks to as late as possible. At least...

The text resource is annoying as it's unavailable from the `Settings` plugin. Regardless, we should use the service and deal with `Settings` plugin as a different issue.

Regarding the performance issue, we could solve it by creating the task using a rule and when we detect an active IntelliJ sync is active. The main issue is resolving...

I remember changing to `compileOnlyApi` because of the following logic, if someone depends on a plugin and builds against it, it should also use the same-ish Gradle API, given the...

There is actually a bigger story here as testing with Gradle includes several competing pieces and each one should be usable individually. ### Gradle Runners Includes all the various ways...

See https://github.com/gradle-plugins/toolbox/issues/56