This sounds to me like a generic problem so I'm wondering if there is a general recommended way to deal with these situations regardless of the build / dependency management tools used (Gradle in my case). I can imagine this issue arising regardless of the build tool, even in a small project where the few dependencies are handled manually and which is simply built with Java using the jar command.
My Java project uses Velocity 1.7 so it has the Velocity 1.7 JARs in its classpath.
However this project also uses ReportNG, which depends on Velocity 1.4 (it even has the entry Class-Path: velocity-dep-1.4.jar in its manifest, plus its downloaded zip contains velocity-dep-1.4.jar and its home page explicitly mentions that velocity-dep-1.4.jar must be in the classpath).
I'm wondering how to avoid having on my classpath the JARs for both Velocity versions, which is the likely cause of strange behavior I'm seeing and which in any case doesn't sound at all like a good idea.
I'm going to try to make ReportNG use Velocity 1.7 instead of 1.4 but it won't necessarily work and I'd like to avoid doing that if there is a clean way of dealing with these situations.
While you can add both JARs to the classpath, by default Java will use first JAR it finds containing a given class, which, depending how you construct your classpath can have undesirable effects on your system.
To avoid this situation Gradle (like Maven before it) resolve dependency conflicts at build time.
With Gradle, the default dependency resolution uses the newest dependency, which in your case means Velocity 1.7.
With Maven dependency resolution is achieved by using the closest dependency to your project, which in your case, as your project declares a dependency on Velocity 1.7, means it is that version that would be used.
With both approaches, whether your system (or rather ReportNG) will work with Velocity 1.7 is down to you to test.