On Feb 26, 2009, at 4:09 PM, Martin Vlcek wrote:
I would rather stay more closely to the current syntax and merge
some of your
suggestions to make it more like groovy instead of a java builder:
configurations {
newConf extends:compile, ...
// and alternatively
newConf {
extends = compile
...
}
}
This is a good point. newConf.extends would also be confusing for Java
users, as the dot notation suggests that newConf already exists.
Therefore I have introduced the create('...') yesterday. But the above
is better. Amongst other things it is more declarative.
repositories {
// like spring DSL in grails the first parameter is the class
publishRepo(OfficialMavenResolver)
otherRepo(FlatFileResolver) {
dir = '/some/path/to/the/resolver/directory'
...
}
This looks interesting. We will play around with this.
// and as alternative format specify all setters map-like after the
first parameter
otherRepo2 FlatFileResolver, dir:'/some/path'
}
dependencies {
// unchanged
compile 'junit:junit:4.+'
// extended syntax to specify (nearly) all possible ivy descriptors
(including configuration!)
compile [org:'my.org', name:'myname', version:'1.+',
conf:'myConf'],
[org:'my.org', name:'myothername', version:'0.+',
We could offer both notations. I'm not sure though, if it is a good
idea to have two different notations in terms of readability. Opinions
on this are welcome.
conf:['myConf', 'myConf2'], ... ]
// for specifying recursive dependencies
compile [org:...] {
compile [org:...]
compile 'junit:junit:...'
runtime '...'
}
// multiple configurations at once (if it's possible?):
[compile, runtime] 'org.apache:log4j:1.+'
Such stuff is not possible with plain Groovy. You would need to do
something like confs(compile, runtime) 'org.apache:log4j:1.+'
}
// instead of archive tasks still use libs, dists:
libs {
myJar {
type = Jar // class name?
name = ...
dependsOn something
// no publication, if no publishTo statement
publishTo repo1, repo2
withConf master, conf1
}
}
I'm not fond of the current libs and dists solution. For a number of
reasons. At the moment libs and dists are additional configurations on
top of the standard configurations. They introduce a singularity. All
this adds clutter. Additionally in 0.5, archives do to much I think.
They shouldn't be aware of configurations and publishing. They should
focus on creating archives. All this adds a framework smell to Gradle
which we would like to replace with the lovely scent of toolsets :).
There is one interesting way one could interpret the notation above.
libs {
myJar { }
}
is equivalent to:
myJar.dependsOn(libs)
On the other hand you might want to have a jar that does not depend on
anything. The role of archiveTasks is to solely provide a factory DSL
for creating archive tasks.
Thanks for your valuable feedback
- Hans
hdockter wrote:
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
--
View this message in context:
http://www.nabble.com/New-DSL-for-0.6-tp22224115p22226102.html
Sent from the gradle-user mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
