gradle-dependency-lock-plugin

A plugin to allow people using dynamic dependency versions to lock them to specific versions.

Explore on GitHub Read Hacker News discussions

3Distinct people

3Mentions

0Explicit recommenders

302GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

A plugin to allow people using dynamic dependency versions to lock them to specific versions.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month3 dated mentions

Observed mentions: 2017-11-11 19:19:53 UTC to 2018-12-06 07:36:29 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Nov 2017	2017-11-01 00:00:00 UTC	2017-12-01 00:00:00 UTC	1	1
Dec 2017	2017-12-01 00:00:00 UTC	2018-01-01 00:00:00 UTC	0	0
Jan 2018	2018-01-01 00:00:00 UTC	2018-02-01 00:00:00 UTC	0	0
Feb 2018	2018-02-01 00:00:00 UTC	2018-03-01 00:00:00 UTC	0	0
Mar 2018	2018-03-01 00:00:00 UTC	2018-04-01 00:00:00 UTC	0	0
Apr 2018	2018-04-01 00:00:00 UTC	2018-05-01 00:00:00 UTC	0	0
May 2018	2018-05-01 00:00:00 UTC	2018-06-01 00:00:00 UTC	0	0
Jun 2018	2018-06-01 00:00:00 UTC	2018-07-01 00:00:00 UTC	0	0
Jul 2018	2018-07-01 00:00:00 UTC	2018-08-01 00:00:00 UTC	1	1
Aug 2018	2018-08-01 00:00:00 UTC	2018-09-01 00:00:00 UTC	0	0
Sep 2018	2018-09-01 00:00:00 UTC	2018-10-01 00:00:00 UTC	0	0
Oct 2018	2018-10-01 00:00:00 UTC	2018-11-01 00:00:00 UTC	0	0
Nov 2018	2018-11-01 00:00:00 UTC	2018-12-01 00:00:00 UTC	0	0
Dec 2018	2018-12-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1

What Hacker News says

3 sources

icebraining·Dec 6, 2018

rely on package developers following semver Well, that seems naive. Almost 1/4th of Maven Central libraries broke binary compatibility in patch updates: https://avandeursen.com/2014/10/09/semantic-versioning-in-ma... Netflix, at least, doesn't agree that Java doesn't need lockfiles: https://github.com/nebula-plugins/gradle-dependency-lock-plu...

In Pipenv: promises a lot, delivers very little

thomaslee·Jul 25, 2018

Exactly this. Or at least it's a way this can be achieved, assuming solid testing & some tooling in the mix. For folks unfamiliar with it, the issue is something like: 1. You find a bug in a library A. 2. Libraries B, C and D depend on A. 3. B, C and D in turn are used by various applications. How do you fix a bug in A? Well, "normal" workflow would be something like: fix the bug in A, submit a PR, wait for a CI build, get the PR signed off, merge, wait for another CI build, cut a release of A. Bump versions in B, C and D, submit PRs, get them signed off, CI builds, cut a release of each. Now find all users of B, C and D, submit PRs, get them signed off, CI builds, cut more releases ... Now imagine the same problem where dependency chains are a lot more than three levels deep. Then throw in a rat's nest of interdependencies so it's not so

Read the rest

me nice clean tree but some sprawling graph. Hundreds/thousands of repos owned by dozens/hundreds of teams. See where this is going? A small change can take hours and hours just to make a fix. Remember this pain applies to every change you might need to make in any shared dependency. Bug fixes become a headache. Large-scale refactors are right out. Every project pays for earlier bad decisions. And all this ignores version incompatibilities because folks don't stay on the latest & greatest versions of things. Productivity grinds to a halt. It's easy to think "oh, well that's just bad engineering", but there's more to it than that I think. It seems like most companies die young/small/simple & existing dependency management tooling doesn't really lend itself well to fast-paced internal change at scale. So having run into this problem, folks like Google, Twitter, etc. use monorepos to help address some of this. Folks like Netflix stuck it out with the multi-repo thing, but lean on tooling [0] to automate some of the version bumping silliness. I think most companies that hit this problem just give up on sharing any meaningful amount of code & build silos at the organizational/process level. Each approach has its own pros & cons. Again, it's easy to underestimate the pain when the company is young & able to move quickly. Once upon a time I was on the other side of this argument, arguing against a monorepo -- but now here I am effectively arguing the opposition's point. :) [0] https://github.com/nebula-plugins/gradle-dependency-lock-plu...

In Why Google Stores Billions of Lines of Code in a Single Repository (2016)

drdrey·Nov 11, 2017

No mention of Java, but I feel like this works reasonably well: https://github.com/nebula-plugins/gradle-dependency-lock-plu... You specify what version constraint you want for each dependency (latest.release, major.+, major.minor.+, a specific version number...). The tool does the work of resolving those constraints to specific artifact references, which you commit to your repo in the form of a dependency.lock file that gives you reproducible builds. You can then resolve new artifact versions with `gradle generateLock`, or revert it to a previous commit if there is a breakage. It's not clear to me what problem OP is trying to solve here.

In The cargo cult of versioning