I really like the fact 'resolver' terminology disappears where it's not necessary. Previously, I had to specify 'addFlatDirResolver' but I just wanted to specify that my libs were in some folder - I didn't want to be exposed to ivy resolvers' interface. Therefore simple 'flatDir' is way better.
Cheers, Szczepan On Fri, Feb 27, 2009 at 11:39 AM, Hans Dockter <m...@dockter.biz> wrote: > > 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 > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
