On 22/09/2011, at 2:41 AM, blackwolf wrote:
> In the end, I decided to hack the gradle source and add my custom dependency
> resolver.
>
> Btw, if any gradle developer is reading this, could we please get the
> ability to install custom dependency resolvers in some future version? It
> seems to me like this shouldn't be too hard to do: if I understand the code
> correctly, you just need to add a
> DefaultDependencyFactory.addDependencyResolver(IDependencyImplementationFactory
> dependencyResolver) method and a similar method on DefaultDependencyHandler
> that calls DefaultDependencyFactory.addDependencyResolver(). Then it seems
> to me like it should be possible to do this:
>
> project.dependencies.addDependencyResolver(myResolver)
I think we'll probably tackle the problem a bit differently to how you suggest.
The use case you describe is something that plenty of other people need to
solve as well (including us for Gradle's own build). So, we plan to provide
some out-of-the-box solution
This might end up as a plugin, where you apply the plugin, provide it with some
logic for where to find the other projects locally, and Gradle takes care of
wiring in an external or project dependency based on what it finds at runtime.
There'll probably be some kind of convention on top of this, so that if you
checkout 'targetProject' to, say $rootDir/../${targetProject}, then Gradle will
just find it and just use it.
The first step towards this solution is, I think, to provide a way to mutate
the dependencies of a configuration at some point before it is resolved. We
want this for other reasons (eg proper api dependencies at compile time, native
dependencies, and so on), but it will also allow us to solve your use case too.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
