Download Gradle User Guide

Fail - fail eagerly on version conflict. Useful if you need extra control and manage the
conflicts manually. Introduced in 1.0-milestone-6. See ResolutionStrategy for
reference on managing the conflict resolution strategies.
Gradle provides means to resolve version conflicts:
Configuring a first level dependency as forced. The feature has been in Gradle since early
days. This approach is useful if the dependency incurring conflict is already a first level
dependency. See examples in DependencyHandler
Configuring any dependency (transitive or not) as forced. The feature was introduced in
1.0-milestone-7. This approach is useful if the dependency incurring conflict is a
transitive dependency. It also can be used to force versions of first level dependencies. See
examples in ResolutionStrategy
To deal with problems due to version conflicts, reports with dependency graphs are also very
helpful. Such reports are another feature of dependency management.
43.2.4. Dynamic Versions and Changing Modules
Sometimes, you always want to use the latest version of a particular dependency, or the latest in a
range of versions. You can easily do this using a dynamic version. A dynamic version can be either
a version range (eg. 2.+) or it can be a placeholder for the latest version available (eg. latest.integration
).
Alternatively, sometimes the module you request can change over time, even for the same version.
An example of this type of changing module is a maven SNAPSHOT module, which always points at
the latest artifacts published.
The main difference between a dynamic version and a changing module is that when you resolve a
dynamic version, you'll get the real, static version as the module name. When you resolve a
changing module, the artifacts are named using the version you requested, but the underlying
artifacts may change over time.
By default, Gradle caches dynamic versions and changing modules for 24 hours. You can override
the default cache modes using command line options. You can change the cache expiry times in
your build using the resolution strategy (see Section 43.8.3, “Fine-tuned control over
dependency caching”).
43.2.5. Dependency management and Java
Traditionally, Java has offered no support at all for dealing with libraries and versions. There are no
standard ways to say that foo-1.0.jar depends on a bar-2.0.jar. This has led to proprietary
solutions. The most popular ones are Maven and Ivy. Maven is a complete build system whereas
Ivy focuses solely on dependency management.
Both approaches rely on descriptor XML files, which contains information about the dependencies
of a particular jar. Both also use repositories where the actual jars are placed together with their
descriptor files. And both offer resolution for conflicting jar versions in one form or the other. Yet we
think the differences of both approaches are significant in terms of flexibility and maintainability.
Beside this, Ivy fully supports the Maven dependency handling. So with Ivy you have access to
both worlds. We like Ivy very much. Gradle uses it under the hood for its dependency
Page 217 of 342