Confusing behavior for updateLock

[sghill]

Running updateLock with no parameters places a new lock file in the build directory (running generateLock). It'd be more intuitive for users of other dependency management systems if this also automatically added the file to the source directory (saveLock)

[jhspaybar]

Oh, that would be nice, but the issue I was getting at was that if you already have a lock file and run updateLock it doesn't actually update the versions of existing dependencies. For example, if I have a dependency on org:foo-lib:1.+ and I'm locked to 1.0.3 when I run updateLock saveLock I'll still be on 1.0.3 even though the tool recognizes there's a newer 1.0.4 version. I have to explicitly run updateLock with an argument telling to bump foo-lib in the lock file. This behavior also differs from existing other language solutions which update everything with no argument or only the thing passed if there is an argument.

[dcow]

Other dependency management solutions don't also have a formalized notion of build artifacts and task inputs/outputs. Because gradle has a bigger scope, the problem can be decomposed more granularly. Something you can do for example is compare the updated lock file with the current lock file for issues or editing before "saving" it. You'd be relying on your version control system to otherwise perform this function. You also get to leverage gradle's ability to evaluate task inputs/outputs when updating or saving (if the newly generated file does not differ from the current one, no actual work should be done).

IIRC saveTask.mustRunAfter lockTask updateTask so you could write a dummy task that dependsOn both and simply run that.

[rpalcolea]

Hey @sghill , can you fill me in on this one? wondering if there are ergonomics we can improve here in the future