Plugin should expose a command allowing individual dependencies to be updated

[jeffwatts]

There is currently nothing in the plugin akin to bundle update <dependency> allowing for more targeted dependency updates. The only way to update dependencies is either to manually edit the dependencies.lock file, which is highly error prone and tedious, or to regenerate the entire lock file, which could update far more than the user intends. A more targeted update command would be a tremendous addition to this plugin.

[rspieldenner]

Any recommendations on how to handle transitive dependency changes from the update?

Quick thought would be to keep locks on all direct but the one being asked to update and let transitives change as defined by new resolve.

[rspieldenner]

Oh and we welcome pull requests if you can add the feature before I get some free time.

[jeffwatts]

I'll try to get you a pull request soon, or have someone from my team do so.

Regarding transitive dependencies, I would hope to update them in a similar way to what Bundler does with the bundle update command. I think it recomputes the greatest acceptable version based on the dependencies being updated, such that it meets all existing constraints between dependencies. I haven't looked too much at your code, though, so I don't currently have a good idea of how much effort this should be.

[dcow]

What about the desired workflow? Will I

$ gradle update --dependency 'my.org:artifact' --version '1.2'

and then after that runs ensure the proper code changes are made to accommodate the update before committing? Or, will I run the above command and expect the update to throw an error if the update cannot be performed without breaking binary compatibility? I suspect the former scenario is more desirable but I'm unfamiliar with bundler too.

[rspieldenner]

So all of our internal jobs generate new locks files and run their test suites before committing the new lock. I figure that's sufficient.

[dcow]

@rspieldenner do you keep your master branch locked, or just release branches? What we're looking for is a way to see exactly what dependencies changed between any two releases (commits really) without the archaeologic excavation that is digging through build logs and our artifact server, etc. We don't want to lock down master with the current implementation because you can't perform targeted updates. We could lock down release branches automatically on branch with a fancy ci job, but that does not give us the lock file to perform diffs with. If we're going to lock down master, we'd like the targeted dependency update functionality.

[rspieldenner]

we lock master branches with a daily job to update the locks (but we have a
large dependency graph).

All release branches are locked and can be used to compare dependency
changes.

You could have your pipeline for releasing include the generateLock
saveLock tasks so the release branches would have the file.

You could have all master jobs run with -PdependencyLock.ignore=true or in
gradle.properties set dependencyLock.ignore=true on the master branch to
ignore committed locks.

On Tue, Feb 3, 2015 at 4:01 PM, David [email protected] wrote:

@rspieldenner https://github.com/rspieldenner do you keep your master
branch locked, or just release branches? What we're looking for is a way to
see exactly what dependencies changed between any two releases (commits
really) without the archaeologic excavation that is digging through build
logs and our artifact server, etc. We don't want to lock down master with
the current implementation because you can't perform targeted updates. We
could lock down release branches automatically on branch with a fancy ci
job, but that does not give us the lock file to perform diffs with. If
we're going to lock down master, we'd like the targeted dependency update
functionality.

—
Reply to this email directly or view it on GitHub
#42 (comment)
.

[dcow]

Thanks for the insight. That may work. If not we'll work on a PR.

[dcow]

Sorry for the spam--I didn't realize a new comment would be generated every time I updated the commit message containing the issue ref. I've drafted an idea for an updateLock task. Let me know what you think.

[bmuschko]

Looks like the corresponding pull request has been merged and a new version was released containing the functionality. Closing the issue.