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.
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:
dependencies.compile.resolve()
vs
dependencies.resolve('compile')
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?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
