Allow impact json to specify url and/or repo, defaulting to impact's repo

[LeafHacker]

trafficstars

Is your feature request related to a problem? Please describe. Currently we map group to maven repo in maven.refmap.json, which made sense when we used upstream maven repos, however now we almost exclusively use our own.

Describe the solution you'd like In this scenario it probably makes more sense to have the installer hard-coded to default to our maven repo* and allow the impact version json to specify an optional override maven repo or absolute jar url for rare cases where we don't want to host the jar (e.g. temp deps for nightlies).

* either hard coded in the jar or set by a file on impactclient.net or an api end point or whatever.

[leijurv]

With the addition of the 3 new mixin deps that are releaseOnly, is it still true that it's almost exclusively our own?

[LeafHacker]

I was under the impression you want to redistribute everything we depend on (in release builds at least) on our own maven, to avoid issues when some random 3rd party maven repo breaks?

[leijurv]

that was more of a lack of trust in dl.liteloader.com specifically -- i have no such worries about actual apache maven going down

[LeafHacker]

I'm still leaning towards the metadata json being the authority on where to get stuff in addition to what to get, whether by specifying a maven repo or a canonical url (we should allow both). If not specified it should fall back either to the existing refmap or some hard coded value.

I know the reason we added the refmap was to allow us to change maven repos for groups in one place, but this also means needing to specify the locations of everything we use there. For release builds that's not really a big deal, but for nighties we could potentially want to add/remove dependencies several times, which would quickly bloat the refmap - or break the nightly if we forget to update the refmap.

[leijurv]

ok i agree with you tbh. only if we do both of them does it make sense to me, but yes, if we host all the dependencies and the metadata json specifies an exact url controlled by us, then that's fine. that's basically what we have now, but with less steps (ad hoc "redirect" lol).

[leijurv]

jesus can we please do this in a way that dosen't invalidate the past jsons tho

getting brady to sign the past releases was like dragging a donkey into a burning building, it took literally >2 months

[0-x-2-2]

that was more of a lack of trust in dl.liteloader.com specifically -- i have no such worries about actual apache maven going down

dl.liteloader.com is run by the dev of mixins.

[LeafHacker]

that was more of a lack of trust in dl.liteloader.com specifically -- i have no such worries about actual apache maven going down

dl.liteloader.com is run by the dev of mixins.

yeah and it went down several times causing Impact to fail to launch.

jesus can we please do this in a way that dosen't invalidate the past jsons tho

This should be "on top of" the current system, optional fields that fallback to either the old way or a hard-coded version of the old way.

if we host all the dependencies and the metadata json specifies an exact url controlled by us, then that's fine.

We could make that part of the release process; have a gradle task publish every lib specified in the release to an ImpactDevelopment/thirdparty maven or something. Circle could then run this on full releases.

We could then have a releaseMetadata task that wraps metadata but assumes everything is on that maven.