Re: [Jython-dev] Versions in extlibs and Gradle

[Eero A. <eer...@ik...>]

Hope I'm not late to the party.

Personally I would prefer to have the defaults the other way around, namely:
- default to fixed versions
- grab the latest versions, if requested.

Although Gradle has the concept of variants, I did not find variant support
Java libraries. Instead, I wrote my own using an environment variable in
https://github.com/eaaltonen/gradle-dependency-proposal

The idea is that you could test against the latest versions of libraries
very easily just by specifying `DEPS=latest` before the build.

--
Eero

On Tue, Aug 21, 2018 at 4:29 AM Adam Burke <ada...@gm...> wrote:

> Good topic. It’s really really good to see Jython moving to declared
> dependency management instead of a jar folder. 2 cents from me ...
>
> At work I have always favoured strictly pinned versions, for determinism /
> repeatability reasons. Being able to reproduce exactly the classes being
> used at a particular point in time can be invaluable with deep dependency
> trees and wide usage of different versions.
>
> People usually aren’t too shy about forcing different dependency versions
> if needed in my experience.
>
> I do see some advantages to the less strict versions, around maintenance
> and advertising to developers the choice of specific version is somewhat
> arbitrary (which it often is, especially when talking about patch versions.)
>
> This blog post has a good discussion about pinned versions
>
> https://brock.io/post/repeatable_android_builds/
>
>
> It also points on to an interesting dependency lock plugin.
>
> https://github.com/nebula-plugins/gradle-dependency-lock-plugin
>
> I haven’t used that plugin in anger, but it might allow the best of both
> worlds.
>
> Cheers
> Adam
>
> 在 2018年8月14日，上午5:36，Jeff Allen <ja...@fa...> 写道：
>
> 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
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Jython-dev mailing list
> Jyt...@li...
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>