@rieske the public interface IncludedBuild used in the settings is also implemented by DefaultIncludedBuild.

All DSL types should be instantiated by the instantiator for Groovy DSL conveniences we do by instrumenting the class.

At the moment it has no practical advantage, because the interface does not have any Action/Closure taking method or properties method. But if it would have e.g.:

gradle.includedBuild('some-build').task('someTask') {
     taskDetails = 'abc' //this does not exist TaskReference today, but imagine it would
}

Then this would stop working for example and you would have to do:

gradle.includedBuild('some-build').task('someTask') {
     it.taskDetails = 'abc'
}

Another example that would stop working I think tis the prop = 'value' shortcut for prop.set('value') (if that interface would use properties).

I think we should still keep using the instantiator here.

Thanks! I'll revert the commit with instantiator then.

What's the rationale for direct instantiation of Java collections without Guava? Should we apply it everywhere?

What's the rationale for direct instantiation of Java collections without Guava? Should we apply it everywhere?

Those Guava helpers were mostly for Java 6 and became obsolete with Java 7 and later. The javadoc for those factory methods says:

Note for Java 7 and later: this method is now unnecessary and should be treated as deprecated. Instead, use the ArrayList constructor directly, taking advantage of the new "diamond" syntax.

And in general - if it is equally convenient to achieve something natively without relying on an external library, I think native should be the preference.
As for whether to apply this everywhere - I think nah, unless it is new code. That's mostly my OCD while I'm blocked waiting for test results.

I see. Thanks, @rieske.