On Oct 19, 2008, at 10:30 PM, Adam Murdoch wrote:
Hi,
I've started adding a Configuration object to our domain model.
Briefly, here's how it looks now. This is still a work in progress:
When you call addConfiguration(), you get back a Configuration
object which you can mutate:
dependencies {
def config = addConfiguration('some-config')
config.private = true
config.transitive = false
config.extendsConfiguration 'compile'
}
You can also supply a configure closure to addConfiguration():
dependencies {
addConfiguration('some-config') {
private = true
extendsConfiguration 'compile'
}
}
Configurations are available as properties of DependencyManager:
dependencies {
addConfiguration('compile')
compile.extendsConfiguration 'api'
}
The analogue here is with tasks: whatever you can do to add and
modify tasks in a project, you can do to add and modify
configurations in a dependency manager (or will be able to, it's
not all there yet).
There are also methods on Configuration to resolve the
configuration, and to get the configuration as a path.
There's nothing yet to add dependencies and artifacts to a
Configuration.
So, some questions:
1. Should we keep the DependencyManager.addConfiguration() method
which takes an ivy configuration? It has a couple of properties
which aren't available on Configuration yet, but these can easily
be added.
We should remove it (but we must not forget to list it as breaking
change in the release notes).
I have a general strategy in mind for working with underlying ivy
object. One way to configure them is via the wrapper. But the wrapper
is not necessarily complete here (e.g. we might not even want to be
complete, or we haven't updated the wrapper object to new features of
a new ivy version). Therefore I would like to offer a fallback to the
user. We provide a method like modifyIvy to the Configuration,
Dependency, ... You can pass a configure closure to this method which
is applied to the newly created ivy object. That way we can always
easily offer 'full' ivy.
2. Should we keep the various DependencyManager.resolve() and
antpath() methods, now you can do this directly on a Configuration?
I think it reads better to call resolve via the Configuration object:
I think so to. Another breaking change to list.
3. I've added the configuration add and lookup methods to
DependencyManager, pretty much because this feels like the default
place to put dependency stuff. What's the difference between
DependencyManager and DependencyContainer? Does some of this belong
on DependencyContainer?
The DependencyContainer has been introduced to factor out common
stuff of both, the dependency manager and the client module.
Configuration does not belong to this common stuff so those methods
are at the right place.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
