Consider `TaskProvider.dependsOn(TaskProvider...)`

[big-guy]

This pattern became illegal in 5.0:

def foo = tasks.register("foo") {
    def bar = tasks.register("bar")    
    dependsOn bar
} 

The simple replacement is:

def foo = tasks.register("foo") 
def bar = tasks.register("bar")
foo.configure {
    foo.dependsOn(bar)
}

If you're willing to reverse the order a bit, you can also do:

def bar = tasks.register("bar")
def foo = tasks.register("foo") {
    dependsOn(bar)
}

If TaskProvider had its own dependsOn, you could also just do:

def foo = tasks.register("foo") 
def bar = tasks.register("bar")
foo.dependsOn(bar)

This is a convenience method.

[big-guy]

I think I'm slightly -1 on this because of the existing alternatives and I think this muddles the distinction between a provider of something and that something.

[trevjonez]

Actual impl would mean at least one more instance of a lambda/closure per use? If that is true, it seems the less convenient API is best in the long run to keep the allocation overhead lower.

[big-guy]

The dumb implementation would be the equivalent of the "simple replacement", unless we did something fancier. If you're already configuring foo, the "reverse" example is the best alternative.

[lacasseio]

I agree with Sterling on this but I was that we could provide factory methods for common configuration pattern like we did in the IDE plugins. For example,

def foo = tasks.register("foo") 
def bar = tasks.register("bar")
foo.configure withDependsOn(bar)

We don't save much but it's close to what this issue is requesting. We could also have withDescription(String), withGroup(String). It's particularly useful in a Java API where you need to create those Action object but given we are moving toward Java 8 and lambdas, then it defeats the purpose of adding those factory methods.

[oehme]

-1 on adding alternative syntaxes, let's have one consistent pattern in the DSL.

[big-guy]

The alternatives are acceptable. closing