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.
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). 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
