#adventure-contrib
2040 messages · Page 3 of 3 (latest)
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)
likely better to just revert it to the original behavior of taking the classloader of the class, instead of introducing a subtle breaking change that may make plugins not work anymore
i mean that's what i did right? make it take the classloader of the class
https://github.com/PaperMC/adventure/pull/1396/commits/fea4cbf16d1124557a1a2d9da0f00ad76e7b3920
ServiceLoader.load(BossBarImplementation.Provider.class)
no, this will use the thread's context classloader
https://github.com/PaperMC/adventure/pull/1396/commits/fea4cbf16d1124557a1a2d9da0f00ad76e7b3920#diff-c10974fac44a8d2a64e6ebb8714785ebc1ba30bb58abd548df0c8afca1e51473L172
usages of the existing method will
https://github.com/PaperMC/adventure/pull/1396/commits/fea4cbf16d1124557a1a2d9da0f00ad76e7b3920#diff-6ec4db75072895f519f99456629eb5e51ba45cb8524bc7dc439c5bc04f2089c9R53
however this has been adapted to use the new method where the ServiceLoader is passed directly
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
adventure 5.1.0 ❤️
what?
is there a branch/PR on fixing the ABI breakage on 5.x?
what API breakage
all API changes like removals in 5.x are intentional as far I am aware
I mean, it was a major version bump for a reason
ABI changes are expected
well its currently blocking it from being bumped in velocity -> https://github.com/PaperMC/Velocity/pull/1774
i read that it may be addressed in adventure itself, is that no longer planned?
that I have no clue, there was no indication of that in the Adventure repo itself but maybe the maintainers have decided something
i see, would love to hear from the maintainers then
? are you referring to #dev-announcements message?
or were there other breaks that release didn't fix?
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
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
might be, was this the only way 5.0 broke the ABI before?
in the velocity PR they're referring to https://github.com/MiniPlaceholders/MiniPlaceholders/pull/371/changes/c75ebb85d615f3f981a20b5629608a3a1c23b8a9
which was needed at least after adventure 5.0
not sure if that would have been fixed by the recent release?
this looks to have been addressed by https://github.com/PaperMC/adventure/pull/1407
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
are javadocs missing for 5.1.1?
5.1.1 hadn't any api changes
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. 
Seconded, if there's anything I can do to help make a proper Dialog api, lmk!
My current to-do list is nbt serializer/dfu stuff, then dialogs and waypoint apis is next on the list!!
Meaning you'll take a look at my Waypoint API PR or make your own?
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?