On Feb 27, 2009, at 8:12 AM, Adam Murdoch wrote:
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)
This should also work:
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', ...
}
I'm not sure any longer what to think about a 'dependsOn' or a similar
term. All this happens already in the context of dependencies.
dependencies {
compile.dependsOn org: 'org', name: 'name', version: 'version'
}
In such a scenario this might be not needed:
dependencies {
compile org: 'org', name: 'name', version: 'version'
}
One question is do we structure the DSL around aspects of
configurations (e.g. dependencies,artifacts, ...) or around
configurations as roots:
compile {
dependsOn ...
publishes ...
}
I'd rather go with the configuration aspects approach. Another thing
is that I think the notations for describing dependencies or artifacts
is DSL specific. It should not be part of the API. For that we need a
context to generate a Dependency from a notation.
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 {
}
In fact, a pre 0.1 version of Gradle behaved like this. At that time
we thought it might be confusing and may lead to subtle and confusing
bugs. For example, you want to configure a task injected by a plugin
but you misspell the name. On the other hand usually you will use non
existing API methods in this case which will lead to a immediate
exception. So I think it is a good idea to provide implicit creation
for tasks.
Or, to define a task with a custom type:
myTask type: SomeType, someProp: 'some-value', dependsOn: anotherTask
alternatively: myTask(SomeType) { ...} or myTask(SomeType, someProp:
'someValue')
- 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.
Good point. With the changes I have applied yesterday and your
proposal, it has lost a lot of its responsibility. What it could still
provide are certain helper methods for archive tasks as well as a
namespace for accessing default jars (e.g. archiveTask.sources). But
we wouldn't need it any longer as a context for a DSL. So I will
remove it from the wiki page.
- 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'
Good point. I'm undecided.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
