On 26/01/2013, at 22:53, Adam Murdoch <[email protected]> wrote:
> Hi, > > A very nice feature snuck into the master branch recently: Dependency resolve > rules can now replace any of (group, module, version) for a requested > dependency. In 1.4, only the version could be replaced. I'm highly suspicious that this "snuck" in. Nothing sneaks into this codebase. > > What this means is that these rules can now be used to solve some interesting > dependency resolution problems: > > * Substituting in an alternative implementation of some module. For example, > I can replace all usages of log4j with a compatible version of > log4j-over-slf4j. > * Dealing with conflicting implementations of some module. For example, I can > replace all usages of the various slf4j bindings with slf4j-simple. > * Dealing with conflicting packaging of some module. For example, I can > replace all usages of groovy and groovy-all with groovy. > * Dealing with modules that have changed their (group, module) identifier. > For example, I can replace ant:ant:* with org.apache.ant:ant:1.7.0 and let > conflict resolution take care of the rest. > * Substituting different implementations at different stages. For example, I > might substitute all servlet API packagings with > 'javax.servlet:servlet-api:2.4' at compile time and the jetty implementation > at test runtime. > > No doubt there's more interesting stuff you can do with these rules. > > Something to note is that these rules are intended to be low level hooks that > you can use to fine-tune the resolution results. Over time, we'll build some > higher-level declarative stuff that sits on top of this. Declarative facts > mean we can infer more stuff, we can do interesting performance > optimisations, and the facts can be published and shared with other builds > (you can already share the rules by packaging them up in a plugin and sharing > the plugin). I'm glad you said this. I was quietly concerned that we were digging a bit of a hole with the imperative rules but suspected this was just the start. > > Also, this isn't the end for consumer-side meta-data. There's plenty more > stuff we can expose. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com >
