Hans Dockter wrote:
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.
This is a good plan. I've made a start on it. I've gone with a
transformer chain approach, as some of the ivy domain objects are not
mutable. It's currently only on DefaultConfiguration. You can add a
Transformer or a closure to DefaultConfiguration. When it assembles the
ivy configuration object, DefaultConfiguration creates a prototype, then
passes it down the transformer chain, and then passes the result out to
the ModuleDescriptorConverter.
Some questions:
- Do these methods belong on the Configuration interface, so that every
Configuration impl must support this? Or a (new) sub-interface, so that
it's optional for an impl? Or is it just an implementation detail?
- Same question for Dependency and GradleArtifact: Does this belong on
the interface, so that every impl must support this?
I'm a little reluctant to add this to the wrapper object interfaces, for
a few reasons:
- It feels like an advanced capability, and adding this to the
interfaces gives a more complex view for beginners to understand
- It tightly couples our domain model to ivy's. I think we should aim to
make it possible to use gradle's dependency management model without ivy
underneath it.
- It forces every implementation to support it, even when its not
required or doesn't make sense
- It doesn't scale well to handling metainfo for multiple, or pluggable,
dependency management systems (eg maven, osgi, or a home spun one)
Having said that, I can't really think of any good alternative to adding
this to the interface (or a sub-interface)
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
