Kotlin-dsl-samples: Support convenience configuration of existing objects in NamedDomainObjectContainer

[bamboo]

See #35.

[oehme]

Can Kotlin do

sourceSets {
  "main" {

  }
}

?

[bamboo]

@oehme, yes and I was considering to use that syntax for #35 since it implies a cardinality of _many_ and it's similar to the Groovy version.

[oehme]

If it can do that, can it also do sourceSets."main"?

[bamboo]

No, not that but it can do sourceSets["main"].

[oehme]

I think that's even better when you think of it as a container or map.

[bamboo]

@oehme, I agree that for accessing an existing element it probably won't get better than that.

How do you envision the configuration of an existing source set, for example?

[oehme]

sourceSets["test“].compileClasspath = configurations["compileClasspath"] + sourceSets["main“].output

[bamboo]

Must be designed together with #35.

[bamboo]

Consider also the contrast between eager and lazy configuration methods such as getByName and withType.

[bamboo]

As of #35, it is now possible to select and configure tasks with the following patterns:

Select single task by name

Use the collection indexer.

task["jar"].dependsOn("someOtherTask")

Configure multiple tasks by name

Invoke the task container (works with any DomainObjectContainer).

tasks {
    "jar" {
         dependsOn("someOtherTask")
    }

    "clean"(Delete::class) { // specify type information so `delete` is available
         delete("someOtherDir")
    }
}

Bring a task into scope for multiple references

Declare a delegated property using the container as a delegate (works with any DomainObjectCollection).

val jar: Jar by tasks
jar.apply {
    from(sourceSets["main"].allSource)
    from(sourceSets["test"].allSource)
}

tasks["build"].dependsOn(jar)