Loading...
The Dependency Catalog
A page that says which libraries your build can actually fetch today — and lets you report one that cannot.
What it is
The catalog at /dependencies is the live answer to "can I actually use this library?". It lists 87 libraries the cloud build knows, and for each one: the exact version it pins, where it is downloaded from, how it reaches your finished jar, and — the part no list can fake — whether that pin still downloads today.
It is a public page. You do not need to be signed in, and you do not need a project open.
What each row tells you
| Column | What it means |
|---|---|
| Version | The version the build pins. **auto** means the resolver looks the version up at build time instead. |
| How it is added | compile only · shaded into your jar · bundled into your jar · provided by the server · installed by the package manager (Discord bots) |
| Status | Whether the pinned version was found in its repository on the day it was last checked |
The repository a library comes from — Maven Central, JitPack, PaperMC and the rest — is not printed on the row. The totals along the top count libraries instead: how many the catalog carries, how many are working normally, and how many have known issues.
Finding one
There is a search box that matches the plugin name, the library name or the Maven coordinate, so you can paste in the coordinate from an old project and see what happened to it. Beside it are filters for the four groups — Server APIs, Plugin APIs, Libraries and Discord bots — plus Known issues, which shows only the entries that are currently broken. Each row copies its coordinate to your clipboard in one click.
Reporting one that will not build
A row whose pin no longer downloads is shown, not hidden, with the plain-English reason — and that row carries a Report this button. Pressing it files the library into the same queue as the wiki's "suggest a library" form, with the coordinate and repository attached, so nobody has to describe the problem twice. You have to be signed in; the button says so if you are not.
A row the page believes is fine has no Report button. If the build cannot find a library the catalog says is working, send it through the Add a dependency form — press Request a library on the Not on the list? card at the end of the page — same queue, and you get to describe what went wrong.
Asking for a library that is not listed
The catalog page also carries an Add a dependency form. It sits at the end of the page, folded behind a Not on the list? card: press Request a library to open it. A search that finds nothing offers a Request this library button too. You need to be signed in for this one. Give the library's name and a link to it — the link is required; submission is blocked without one — plus, if you know it, its Maven coordinate (group:artifact or group:artifact:version; the form marks that field optional), and it goes into the same review queue. You can attach the .jar file itself (up to 25 MB). An attached jar is scanned first: if it is clean and the library is not already available, it is installed for every project straight away, and the page says it "is installed — every project can compile against it now." Otherwise it waits for a person to check it, is refused ("was not installed."), or is reported as already available. If the file itself is refused — too large, or you have already sent five that day — your suggestion still lands, only the jar stays behind.
After you submit, a Yours chip appears among the filters, listing what you have sent that is still waiting. That list lives in your browser: an entry disappears on its own once the library shows up in the catalog, and a suggestion that goes nowhere quietly expires from the list rather than claiming to be under review forever.
The date at the top is the point
The header says when every coordinate on the page was last checked against its repository — 3 August 2026. A library list with no date cannot tell you the difference between "this works" and "this worked when somebody typed it out" — three pins were dead the day this page was built, and the only way anyone found out was a generation failing on Could not find….
A library missing from the catalog is not automatically a dead end. Anything on Maven Central or a public GitHub repo still resolves on its own — just ask for it in the Code Studio and build. The catalog is the list of the ones VyroAI has checked, not the list of the ones allowed.
Where to next
- Just browsing what exists: Available Dependencies — The same libraries, listed inside the wiki.
- If yours is missing: Custom Dependencies — For a library the catalog does not carry.
- Before your first compile: Cloud Build — What the build does with them.
21 of 22 in Minecraft Studio · Last checked 12 September 2026 · Previous: Available Dependencies