Deleting ~/.gradle/cache from time to time can be most illuminating :-) Building Gradle seems to pull down SVNKit 1.1.6, but they are now on 1.3.0 (also JUnit 4.5 is pulled in but 4.6 is available, etc., etc.) which brings up the issue of what the strategy and policy is for Gradle and upgrading its dependencies -- and indeed dependency management for applications as well.
I think there are a number of scenarios and all should be handleable
easily.
1. Keep up to date automatically with the latest versions available in
the repositories searched. Maven allows this I think, but I am not sure
Gradle does -- it requires version numbers to be specified (unless I am
just missing something).
2. Ensure that the versions of dependencies available on the platform
in use are used. This is the Debian/Ubuntu situation where dependencies
are managed by the platform and not by the application. Maven and
Gradle do not seem to have the facilities to allow this as an easy
option.
3. Specify that the jars in some directory or other are used whatever
their version numbers. I am sure there must be a way of doing this in
Gradle but I have not got the idiom yet.
4. Specify exact version numbers for each direct dependency and rely on
transitive dependency specification (implicit or explict) to handle the
rest. Maven and Gradle seem to handle this well, but at the expense of
this being effectively mandated.
--
Russel.
=============================================================================
Dr Russel Winder Partner
xmpp: [email protected]
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip: sip:[email protected]
London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
signature.asc
Description: This is a digitally signed message part
