Hans Dockter wrote:
Hello,
we are working intensely on Gradle 0.6. One focus is to make our DSL
more intuitive. To achieve this we are improving the syntax of the DSL
as well as how the different elements play together.
Here is a link to the current draft of the new DSL:
http://docs.codehaus.org/display/GRADLE/Dependencies
We are very interested in your feedback.
Some comments:
- Should the key for a dependency be {organisation, module}, rather than
{organisation, module, version}?
- If Configuration dependsOn() were to declare a single dependency,
rather than to allow multiple, you wouldn't need the square brackets:
compile.dependsOn(org: 'some.org', name: 'name', version: 'version)
Further, if a configure closure were used with the configuration, you
could do:
compile {
dependsOn org: 'org', name: 'name', version: 'version'
dependsOn org: 'another', name: 'another', ...
}
or
confs(runtime, test) {
dependsOn org: 'org', ....
}
- Given that configurations and repositories are implicitly created when
first referred to, I think we should do the same for tasks. For example,
the following would create task 'myTask', with type DefaultTask, and
attach a task action to it:
myTask.doFirst {
}
Or, to define a task with a custom type:
myTask type: SomeType, someProp: 'some-value', dependsOn: anotherTask
- What does the 'archiveTasks' section do? If we were to do the above,
it doesn't look like we would need the 'archivesTasks' section at all.
- If I declare some repositories in the 'repositories' section, it would
be good if they did something useful by default. For example, they could
be used for resolving dependencies if I don't explicitly declare the
resolvers to use for resolving. And the first one could be used for
uploading artifacts if I don't declare otherwise.
- We could use a configure closure with the artifacts as well:
master {
publishes someFile, another file
}
- Are we using the term 'org' or 'group'? The example uses 'org', but
Project currently uses 'group'
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
