On 13/05/2013, at 1:11 AM, Adam Murdoch <adam.murd...@gradleware.com> wrote:
>
> 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.
We should park this then until we know what we are doing there.
Is there a spec where I can add a note to expose the projects as a DSL enabled
container?
> 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).
That is a rather large can of worms you are proposing to open.
So the summary of this seems to be "no". We won't be doing this.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA:
http://www.gradlesummit.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
