From: Jeff A. <ja...@fa...> - 2018-08-13 19:36:28
|
One of the things we were looking forward to with Gradle was that it would become easier to control the versions of JARs (modules) we depend on. Gradle can get quite sophisticated about this: you can have anything you want. Only ... what do we want? * If we only specify a module name, we'll get the latest all the time (with obvious risks). * If a module moves to a new API we aren't ready for, we can specify the version in part (3.1.+), and continue to take minor/patch releases. * If a module has to be pinned to an exact version, we can name it explicitly (or an acceptable range). At least we don't have to check the JAR in: just change the dependency statements (once we use Gradle exclusively). If we build distributions with Gradle like the JARs we build now, I believe we end up jarjar'ring the dynamically downloaded modules, but I haven't tried that yet. A second dimension is when other projects cite Jython as a dependency and get our dependencies transitively. Consuming projects are able to override our version choices (if I understand correctly, https://docs.gradle.org/current/userguide/managing_transitive_dependencies.html#sec:enforcing_dependency_version). The less specific we are about version, the more helpful to consumers. However, these might be untested combinations. Any thoughts how to tell, for a given module, what the sensible policy would be? -- Jeff Allen |