Any documentation/examples of what this looks like?
On 01/26/2013 04:53 PM, Adam Murdoch 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.
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
