This message was deleted.

We're doing something quite similar (in about 70 lines of groovy DSL which I sadly cannot share), but only for specific configurations and with filenames that can easily be filtered, so they can get special treatment (i.e. need for approval) in a PR when changed. Also, we do not fail the build when dependencies are removed, which might be an option worth considering for your plugin as well.

Nice! That is an interesting point about removals only. I'll think about that one. The plugin I have supports 3 formats: artifact list, module list and tree formats. For all main purposes the artifact list is most used, but for upgrades the tree one is super useful. What do you do when they are removed then, how do you rebaseline?

Obsolete entries are usually only removed when other changes make an approval necessary, anyway. Then whoever introduced a new/updated dependency needs to run the rebaselining task in their PR branch.

That makes sense, but won't that allow a removed library back in? For example, if I pull out leak Canary and don't re-baseline and then somebody adds it back in?

This is mostly not a problem for us, since when a library is approved, it usually stays approved. If not, the remover could just manually re-run the baselining and it would be gone.

Thank you. In this case for an Android app, the less dependencies, the smaller the app size. Additionally, the addition or removal of a dependency can impact the behavior of the code. So we would want to try and make any additions or removals accounted for.