Provide accessors for elements of specific Gradle collections such as tasks

[bamboo]

In order to enable discoverability of such elements in the IDE and provide a DSL closer to Groovy.

For instance, to configure the test task one would be able to write:

plugins {
  java
}

tasks {
  test {
    useJUnitPlatform()
  }
}

[StefMa]

To be honest I want to switch to the Kotlin DSL do don't get close to the groovy version 😂

…

On Wed, May 16, 2018, 3:47 PM Rodrigo B. de Oliveira < ***@***.***> wrote: In order to enable discoverability of such elements in the IDE and provide a DSL closer to Groovy. For instance, to configure the test task one would be able to write: plugins { java } tasks { test { useJUnitPlatform() } } — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#879>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJwYex-qiIh6aKsuGPrBLkstUpfZmTRhks5tzC4IgaJpZM4UBWFW> .

[eskatos]

In order to be able to implement this we would need the Gradle API to provide a schema for containers declaring the name and public type of each element. This would be similar to the schema of the extensions container provided by: https://github.com/gradle/gradle/blob/cf6d0508131b0ff9d6354b3d46f83bcf5ca8f8a4/subprojects/core-api/src/main/java/org/gradle/api/plugins/ExtensionContainer.java#L157-L163
For performance reasons, realizing that schema should not trigger the realization of the container elements. Names and types are known at element registration time so it shouldn't be a problem.

[eskatos]

First step, lazy-friendly, is in progress at gradle/gradle#6142

#222 will get in the way of distinguishing containers, we'd need a specific container scope type for tasks {}