On Fri, Dec 11, 2009 at 8:11 PM, Adam Murdoch <[email protected]> wrote:
> Hi,
>
> I've just checked in a first pass at providing a way to configure the
> project using an external build script. The DSL currently looks like this:
>
> apply {
> // apply the script to the project
> script 'somepath.gradle'
> }
>
> You can also configure any set of arbitrary objects:
>
> apply {
> // apply the script to main and test sourcesets
> script 'somepath.gradle'
> to sourceSets.main, sourceSets.test
> }
>
> You would also be able to, for example, use apply { } in a subprojects { }
> section.
>
>
Adam, this looks great and is exactly what I was looking for! I will try it
as soon as I can (see note below)...
> Currently, this only available from a build script, but I plan to make it
> available from any script.
My problem is I need it from the settings.gradle. Any idea on when that
might be done? That's when I'll know if it really works for me.
> Also, I'd like to move plugin declarations into the apply { } section, and
> deprecate usePlugin():
>
> apply {
> plugin 'java'
> plugin SomePluginClass
> }
>
> Then, a script is effectively just another way to implement a plugin.
>
> Also, I'd like the script() and plugin() methods to accept a URL or a
> dependency specification to declare which script/plugin to use.
>
That would nicely move us towards a plugin ecosystem. Sounds promising.
>
> Some questions:
>
> - Anyone have any thoughts on a better DSL? Another option is to use a map
> based method:
>
> apply script: 'something.gradle', to: sourceSets.main
>
> or to use both.
>
> - Should we do away with the distinction between scripts and plugins?
> Something like:
>
> configure {
> use 'somescript.gradle'
> use JavaPlugin
> }
>
> or
>
> apply 'some.gradle'
> apply JavaPlugin
> apply 'some.gradle' to: sourceSets.main
>
>
I think I prefer a single argument version and a map based approach. I
think this reads nicely:
apply 'java'
apply SomePluginClass
apply script: '/path/to/script.gradle', to: sourceSets.main
I don't know how the "apply 'some.gradle' to: sourceSets.main" that you
suggested above would work. Also, you could group all these in an apply {}
closure, but I don't see the need.
- Should we allow plugins to be applied to anything? This would mean
> changing the plugin interface to something like:
>
> public interface Plugin<T> {
> void use(T target)
> }
>
>
I don't understand what you are getting at here. Could you give an example,
or maybe just describe the idea a bit more. All in all, I think this is a
powerful approach that could lead to several more changes in Gradle. Good
job!
--
John Murph
Automated Logic Research Team
