Devs,
I have a few proposals regarding our dependency notation.
1. I strongly prefer the String notation over the Map notation. I find
`"foo:bar:1.0"` both more readable and more writeable than `group: "foo",
name: "bar", version: "1.0"`. It's a DSL at its best. However, most of our
documentation and hence most of the build files I come across use the clumsy
map notation.
Proposal: Promote the String notation and use it throughout our
documentation.
2. Once more advanced dependency attributes come into play, the String
notation is no longer sufficient. This already holds today for the
`configuration` attribute (which can't be set on the object because it is
designed to be immutable) and I assume we'll have more of this in the
future. Currently, adding such an attribute forces me to switch from String
to Map notation, which is disruptive and violates 1.
Proposal: Allow mixing of String and Map notation. Example:
dependencies {
compile "foo:bar:1.0", configuration: "api"
}
This combines the best of two worlds: the conciseness of the String
notation, and the generic nature of the Map notation.
3. As a student in one of my trainings pointed out, there is an
inconsistency between
dependencies { compile group: "foo", name: "bar", ... }
and
dependencies {
compile(...) {
exclude group: "foo", module: "bar"
}
}
I can see where this is coming from: Contrary to the 'name' in the
dependency notation, the `module` in the exclude rule has to be able to
stand on its own. But it still feels a bit odd that we use different terms
here and there.
Proposal: Use the same term in both cases (either `name` or `module`).
Let the voting begin.
--
Peter Niederwieser
Principal Engineer, Gradleware
http://gradleware.com
Creator, Spock Framework
http://spockframework.org
Twitter: @pniederw
--
View this message in context:
http://gradle.1045684.n5.nabble.com/Proposals-regarding-dependency-notation-tp5022817p5022817.html
Sent from the gradle-dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
