On Feb 12, 2009, at 12:04 AM, Hans Dockter wrote:
On Feb 5, 2009, at 9:28 PM, Adam Murdoch wrote:
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.
It was a first try. I have added some more ideas to the page. But to
use maps instead of strings makes a lot of sense I'd say. It is
important to note that the original sample was not valid Groovy code.
Unfortunately you can't say: meth [org: 'someOrg']
You always have to use parentheses if you pass a map: meth([org:
'someOrg'])
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
That's the idea. Client module has been a confusing name.
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).
I have done too much Java lately. The parentheses can go of course
before the curly bracket of the closure.
However, how would you share the module declaration across multiple
configurations (other than by extending the configuration)?
In my new sample:
confs(compile, runtime).dependsOn(module(...))
What you could also do is:
Module module1 = module(....)
compile module1
runtime module1
or something like
module1.configurations = [compile, runtime]
This points to what I think is an important issue. I think
dependency objects should be entities. We should guarantee
uniqueness per dependency container. The key of a dependency would
be (org, name, version).
Perhaps somthing like:
dependences {
hibernate = module [name: 'hibernate' ... ] { }
compile hibernate
myOtherConfiguration hibernate
}
I think we don't need it for the use case above. But in general it
might be an interesting mechanism.
After a bit of sleep ...
This would be one solution to the problem. But the above mechanism
does not necessarily need to create an extends relationship between
configurations.
myOtherConfiguration hibernate
could also add the myOtherConfiguration to all dependencies of the
hibernate configuration.
- Hans
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')
}
This is much nicer. I have picked up this idea and added a sample to
the wiki page. I'm not sure if we should really use dependsOn, as
this is used for task dependencies.
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?
I haven't thought about this yet.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
