#adventure-contrib

2040 messages · Page 3 of 3 (latest)

deft stirrup
#

dont mind how horrible of syntax that is though lol

latent bobcat
#

well, the "proper" usage would be to not pass a cl explicitly

the whole reason the classloader was being passed alongside the class itself was precisely because of plugins shading, it's telling the loader which classloader to look for service impl
getting rid of that will make it look up in the thread's context classloader, which, unless the plugin is changing it up, Paper sets to, well, Paper's own cl; so it will look for an impl in a classloader that doesn't have it

what many big frameworks (spring, hibernate, etc etc) do is they allow you to configure which cl to load services from, but by default they use the ctx cl; but these frameworks' service loading is much more DI'd, adventure's isn't (all of these usages are global)

deft stirrup
wild crane
#

i mean that's what i did right? make it take the classloader of the class

wild crane
#

oh right yes so it needs to be ServiceLoader.load(BossBarImplementation.Provider.class, BossBarImplementation.Provider.class.getClassloader())

#

this just feels like peak java now Services.service(ServiceLoader.load(BossBarImplementation.Provider.class, BossBarImplementation.Provider.class.getClassLoader()), BossBarImplementation.Provider.class);

#

okay yes that should be good now then

deft stirrup
#

adventure 5.1.0 ❤️

warped fable
chrome parrot
#

is there a branch/PR on fixing the ABI breakage on 5.x?

crisp portal
#

all API changes like removals in 5.x are intentional as far I am aware

chrome parrot
#

application binary interface

#

changing classes to interface or vice versa

crisp portal
#

ABI changes are expected

chrome parrot
crisp portal
#

that I have no clue, there was no indication of that in the Adventure repo itself but maybe the maintainers have decided something

chrome parrot
#

i see, would love to hear from the maintainers then

candid solar
#

or were there other breaks that release didn't fix?

shy sandal
#

you'd need to be a bit more specific what you mean with "the" ABI breakage, 5.1.0 already released with a fix for one

crisp portal
#

I imagine they're talking about whatever is currently blocking the update to Adventure 5 in velocity, but I believe that's mostly just people being busy. Paper itself hasn't updated to adventure 5 either

chrome parrot
#

not sure if that would have been fixed by the recent release?

wild crane
#

Yes the Component#build ABI break is fixed in 5.1.1. If you encounter any others do open an issue! We only found out about this one a week or so after due to someone mentioning it offhand :')

#

Can only fix what we're aware of

deft stirrup
#

are javadocs missing for 5.1.1?

vocal wasp
#

5.1.1 hadn't any api changes

latent bobcat
#

it doesn't really need any

#

it's just Maven publishing changes

teal cliff
#

Hi, Adventure Contributors!
Just another ping of Dialog API. It's been a year since 25w20a, the first version of Dialog API. Since 1.21.6 pre3, the Dialog API remained unchanged except a minor adjustment in 26.1 snapshot-3.
If this is help-wanted, I'd love to contribute. paper

rotund ravine
#

this Seconded, if there's anything I can do to help make a proper Dialog api, lmk!

wild crane
#

My current to-do list is nbt serializer/dfu stuff, then dialogs and waypoint apis is next on the list!!

warped fable
chrome parrot
#

https://github.com/PaperMC/Velocity/pull/1774#issuecomment-4548682646

See last couple of comments here (last one is my take on this)

Velocity currently makes use of (and provides pointers through) platform-facet, which is now deprecated. This should never have been the case as its clearly stated as an internal API, but plugins might now be relying on this, so removing the deprecated dependency in Velocity could be a breaking change...

Would it ever be considered to get net.kyori.adventure.platform.facet into adventure-api and have it be an officially supported (non-internal) part of it?