After a successful proof of concept earlier this year, we’ve started using Gradle (instead of Maven) for new projects at work. One of the first things you might notice about Gradle is that (a) it’s new enough that there isn’t a plugin for every random requirement out there, and (b) it’s flexible enough that the missing plugins aren’t usually a problem — you just implement the functionality yourself.
Here’s a quick task that will let you know if your dependencies need to be updated, a la mvn versions:display-dependency-updates. It’s actually a bit longer than most Gradle snippets, so I suspect there’s a way to express it more succinctly. The irony, of course, is that it relies on the Maven central repo to determine whether or not any of your dependencies are out of date.
// Find any 3rd party libraries which have released new versions
// to the central Maven repo since we last upgraded.
task checkLibVersions << {
def checked = [:]
allprojects {
configurations.each { configuration ->
configuration.allDependencies.each { dependency ->
def version = dependency.version
if(!version.contains('SNAPSHOT') && !checked[dependency]) {
def group = dependency.group
def path = group.replace('.', '/')
def name = dependency.name
def url = "http://repo1.maven.org/maven2/$path/$name/maven-metadata.xml"
try {
def metadata = new XmlSlurper().parseText(url.toURL().text)
def versions = metadata.versioning.versions.version.collect { it.text() }
versions.removeAll { it.toLowerCase().contains('alpha') }
versions.removeAll { it.toLowerCase().contains('beta') }
versions.removeAll { it.toLowerCase().contains('rc') }
def newest = versions.max()
if(version != newest) {
println "$group:$name $version -> $newest"
}
} catch(FileNotFoundException e) {
logger.debug "Unable to download $url: $e.message"
} catch(org.xml.sax.SAXParseException e) {
logger.debug "Unable to parse $url: $e.message"
}
checked[dependency] = true
}
}
}
}
}
Anonymous said,
August 8, 2011 at 7:38 pm
If I remember correct, if you give “+” at the end of the version, Gradle will check the repo to find the latest version higher than the the one you give, for example 1.0+ means latest one higher than 1.0.
Daniel Gredler said,
August 8, 2011 at 9:28 pm
The problem with version ranges is that you’re sacrificing build reproducibility for a little convenience. Version ranges can be useful during the initial stages of prototyping, but at some point you want to lock your version numbers down, or you’re asking for build surprises down the road. That’s when things like the Versions Maven plugin or the snippet above come in handy, to make it easier to upgrade in a controlled way.