Hans Dockter wrote:
I have started to create a Wiki page for reviewing our DSL in general.
So far I have added page with some ideas how our new dependency DSL
could look like:
http://docs.codehaus.org/display/GRADLE/Dependencies
Generally, this look really good. I like the separation of repositories,
configurations, dependencies and publications into separate concepts.
Some questions/comments:
It looks like a configuration is implicitly created when it is first
referenced. I think this would be a good thing. Perhaps it should only
happen while the configurations { } closure is executing.
It also looks like you can configure a domain object using either a map
or a closure or both. I think this would be good. We should also apply
this approach to pretty much every domain object create/add/configure
method - tasks, repositories, projects, and so on.
I like the new format for dependencies. Do you think we would keep the
'group:module:revision' format as well? We probably should deprecate it
and keep it for a few releases before removing it.
Have client modules been replaced by 'module'? Ie
runtime (module [name: 'hibernate', ... ] {
add [some dep]
....
})
I like that the module is treated the same way as other dependencies
(provided we can get rid of the parentheses around the module). However,
how would you share the module declaration across multiple
configurations (other than by extending the configuration)? Perhaps
somthing like:
dependences {
hibernate = module [name: 'hibernate' ... ] { }
compile hibernate
myOtherConfiguration hibernate
}
Also, 'add' could be something like 'dependsOn' to describe the
semantics better, and to match task dependencies. I think for
readability it would be nice to optionally do:
dependencies {
compile dependsOn [name: 'someLib']
compile dependsOn project(':a')
}
For the publications, how do I declare which task(s) build each
artifact? How do these relate to the archives declared in the archives
{} section?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
