On 10/05/2013, at 11:40 PM, Luke Daley <luke.da...@gradleware.com> wrote:
> Hi,
>
> The idea of a findProject(String, Action) method is to support partial
> builds, where subprojects may not be part of the build for a particular
> invocation. This is usually done with partial checkouts or some contextual
> configuration in settings.gradle.
>
> To do this in a build script looks like this…
>
> def subproject = findProject(":foo")
> if (subproject) {
> configure(subproject) {
>
> }
> }
>
> Which would be replaced with:
>
> findProject(":foo") {
>
> }
>
> The find* aspect grates a bit, but I'm proposing it on the grounds that using
> find* is an established pattern in our API for getting something that might
> not be there, and that's ok. Combine this with the common pattern of
> configuration closures/actions and I don't have a problem with the name.
Rather than add a DSL specifically for this use case, I'd rather add something
to our container DSL and expose the projects via a container, perhaps something
like this:
projects.find(':foo') { … }
You'd also use this DSL (whatever it looks like) for things like: do this stuff
when the java plugin is present, do this when the test source set if present,
do this when the mavenCentral repository is present, and so on. It also
overlaps with the stuff we've been talking about in the 'polymorphic
containers' thread.
I'm sure we can come up with a better name than 'find' for the method, if we
want to.
Another option would be to start growing a new decoupled configuration
injection DSL in `settings.gradle`, which needs to solve exactly this use case
(amongst many others).
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA:
http://www.gradlesummit.com
