Retrieve authoritative vendor JSONs from URL

[JaciBrunning]

Currently, it's required that vendors submit a PR to this repository every time they update their library with a copy of their vendordeps file. In many cases, this vendordep file is already hosted somewhere else (defined in the "jsonUrl" property). Having to update this repo adds friction to the automated CI/CD process that some vendors use in publishing their builds, and also introduces a source of data duplication.

Given vendordeps can be hosted pretty much anywhere on the internet (including as a raw github artifact), I don't see why we need to duplicate this data here. If a "bundled" copy is required for downstream tooling that uses this, can we invoke that as a build process as opposed to committing vendordeps in-tree?

[ThadHouse]

I’m actually tempted to go the other way. Remove the jsonUrl and force this repo to be the authoritative source.

This way there’s a set known place where all supported vendor deps are, and it’s easy to know when updates are actually released.

[jasondaming]

Many vendors also do not keep previous versions of their json files instead choosing to only link a "latest". While this is fine in many cases it removes the ability for the user to return to a previous version.

[sciencewhiz]

There's also #60 for CI integration.

[legoguy1000]

I like the json url in the file, I use into automatically update my vendor deps using a scheduled GitHub action to poll the url. See Frc5572/Java-Template#36. This repo and the new extension is nice but I don't think it should be the only place the files are found

[virtuald]

It's nice to have a single location that you can watch for vendor updates (or get email notifications) AND know what all the vendors are.

If this is enough of a pain point, someone could write a cron job for this repo to poll a variety of vendor urls and auto-PR them here; or write a script that vendors could use that takes a github token to PR the json file here.

[JaciBrunning]

I think Cron might be best. CI is doable but I imagine keeping track of access tokens / permissions for a large number of vendors can get difficult

[virtuald]

Each vendor would manage their own token and usage of the script, so it would spread the work around. As @sciencewhiz mentioned, looks like #60 has a combination of the script and a github action that vendors could use.