irrelevant

Agreed. My own plugins were among those that were straightforward to resolve (and have been). Keep improving Spigot.

> Just trying to improve the server and API, what do you suggest as an alternative?

I am not a dev, I just get scared when things change as i run the server and try to figure out why. I am glad things move forward and get improved. I Just see spigot point to devs, and devs point to spigot. I am just sitting here going: ok, guess ill ignore these msgs too. i dont think an alternative for devs is to add all the entries in plugin yml though. but then again, i hardly understand how devs have to properly handle this. 

SlimeDog transient dependencies was already resolved

Transcient dependencies seem to be a difficult issue. But most plugins do not have that difficulty, so the dependencies are relatively easy to resolve. Many already have done so.

While I find the warnings annoying, they are just warnings. They can be easily ignored, or even elided with ConsoleSpamFix and the like.

>turns out it's another spigot thing that recently changed causing more stuff to spit out to console.

Just trying to improve the server and API, what do you suggest as an alternative?

I thought I was doing something wrong and tried to fix this, rolling back plugins and i dunno what.. turns out it's another spigot thing that recently changed causing more stuff to spit out to console. Meh. glad it's not on me. 

Trying to report this to devs, but seems others already have; 

https://github.com/PlaceholderAPI/PlaceholderAPI/issues/236 (point of view of another dev i guess about this).

Seeing how opinions are so split on this I doubt these "warnings" and such will not go away any time soon. 

Thank you for removing the warnings for transitive depends.

I understand your point about wanting Bukkit plugin loading to behave like a proper module system - but quite how likely this is I'm not so sure.

Perhaps a nice middle ground would be allowing plugins to declare their dependency on another plugin - either during or sometime after the PluginEnableEvent is called. That way theoretically, the plugin loader could still implement module isolation if it wanted to.

The point of this change is to point out the incorrect use of non-existent relationships. There is currently a non-existent dependency relationship of LuckPerms->Vault.

You could argue that on that basis, all dependencies declared using loadbefore are "non-existent".

That was the point I was trying to make when I said "there is now no valid use-case of loadbefore" previously.

Latest version adds support for transitive depends.

>Not sure how this would be possible given the current system - depends have to be declared in the plugin.yml, no? Expansions would be loaded after that is defined.

Bukkit has a comprehensive PluginLoader API that PlaceholderAPI could/should be using to treat expansions as plugins. This is commonly done for plugins written in other languages (eg a Java plugin loading python scripts as an expansion), a goal which Bukkit was designed to provide first class support for. If that API doesn't work the author is free to work with us on a better solution, but it would still need to retain a proper dependency relationship.

>What is the issue? LuckPerms doesn't attempt to use Vault classes until after Vault has been loaded and enabled using the PluginEnableEvent. This is the same guarantee as the dependency system provides - so what's the problem?

It's not though, consider what I said above about 'with the ultimate goal that the system may one day behave like a proper module system that many want'. If plugins were treated like OSGI bundles, Java Servlets (as they should have been when Bukkit was made), or now Jigsaw Modules, such an access would be impossible. It's only possible currently because Bukkit dependencies are entirely weak rather than strong. Strong dependency relationships have been the norm elsewhere for over a decade, and since Java 9 are the norm in Java itself. The point of this change is to point out the incorrect use of non-existent relationships. There is currently a non-existent dependency relationship of LuckPerms->Vault. You can't spin that any other way, the Javadocs are crystal clear about it from 5+ years ago. LuckPerms has a soft dependency relationship on Vault which it has not properly declared. Full stop.

>That is exactly the point. There is now no "valid" (according to the warnings Spigot has implemented) use-case of the loadbefore property.

No, the warnings handle loadbefore according to its documented behaviour: https://hub.spigotmc.org/javadocs/spigot/org/bukkit/plugin/PluginDescriptionFile.html#getLoadBefore--
"Specifying another plugin here is strictly equivalent to having the specified plugin's getSoftDepend() include this plugin."

In that case the expansions should declare depends.

Not sure how this would be possible given the current system - depends have to be declared in the plugin.yml, no? Expansions would be loaded after that is defined.

Given LuckPermissions loads at STARTUP which is far earlier than most plugins, I feel like the intersection of (plugins loading at startup ∩ depending on vault ∩ misusing Vault) is very small 

The intersection was large enough for it to be a problem.

When LuckPermissions then tries to use Vault classes without a dependency relationship, there is obviously an issue

What is the issue? LuckPerms doesn't attempt to use Vault classes until after Vault has been loaded and enabled using the PluginEnableEvent. This is the same guarantee as the dependency system provides - so what's the problem?

while it may be justifiable in practice theoretically it is completely broken (as is arguably the loadbefore option in the first place)

That is exactly the point. There is now no "valid" (according to the warnings Spigot has implemented) use-case of the loadbefore property.

Even tho this is a minor thing and unrelated: The plugin's name is LuckPerms... Not LuckPermissions...

Like I said. Minor thing, yet important in a way.

> As for the issue with LuckPerms, I replied to you on GitHub - please see https://github.com/lucko/LuckPerms/issues/1959#issuecomment-578708071 - what I'm doing there seems reasonable to me.

The problem is dependencies are by definition a directed graph and you are trying to treat them as an undirected graph.
https://en.wikipedia.org/wiki/Dependency_graph – "a dependency graph is a directed graph representing dependencies of several objects towards each other."

Yes I get what you're doing, and while it may be justifiable in practice theoretically it is completely broken (as is arguably the loadbefore option in the first place). You're trying to fix plugins misusing Vault, we're trying to fix plugins misusing depends (with the ultimate goal that the system may one day behave like a proper module system that many want).

Given LuckPermissions loads at STARTUP which is far earlier than most plugins, I feel like the intersection of (plugins loading at startup ∩ depending on vault ∩ misusing Vault) is very small and those plugins should just be fixed rather than you breaking your own dependency relationships.

What you're saying is "Vault (soft)depends on LuckPermissions but LuckPermissions does not (soft)depend on Vault". When LuckPermissions then tries to use Vault classes without a dependency relationship, there is obviously an issue. This is not some sort of unique Spigot limitation, every (Java or otherwise) module implementation would have the same result.

>Additionally, transitive (soft)depends don't seem to be accounted for.
Yes, acknowledged, but a minor issue.

> 11:42 <Luck> I think I understand the rationale behind adding the warning, but there are some cases where declaring a soft(depend) on everything used is not practical, e.g. PlaceholderAPI etc

In that case the expansions should declare depends.

Quoted from IRC:

11:42 <Luck> Hey, re: Bukkit commit "Print warning when loading classes from depends that have not been specified", would be be possible to add some way for plugins to dismiss those messages?
11:42 <Luck> I think I understand the rationale behind adding the warning, but there are some cases where declaring a soft(depend) on everything used is not practical, e.g. PlaceholderAPI etc

 
As for the issue with LuckPerms, I replied to you on GitHub - please see https://github.com/lucko/LuckPerms/issues/1959#issuecomment-578708071 - what I'm doing there seems reasonable to me.
 
Additionally, transitive (soft)depends don't seem to be accounted for.
See: https://github.com/LuckPerms/ExtraContexts/issues/18#issuecomment-578728414
 
It seems unreasonable to expect plugin developers to include transitive dependencies in their plugin.yml - otherwise what would be the point of CraftBukkit having recursive dependency resolution in the first place.

No, see https://github.com/lucko/LuckPerms/issues/1959#issuecomment-578695633

This seems to, somehow, be bugged as plugins like LuckPerms give this warning despite the fact that they have the mentioned plugin(s) as either (soft)dependency or loadbefore.

See the following GitHub issue on LuckPerms for context: https://github.com/lucko/LuckPerms/issues/1959

For anyone looking at this ticket, there is at least one message that seems like a false positive, but isn't:

 [22:04:13] [Server thread/WARN]: [MobHunting] Loaded class org.inventivetalent.update.spiget.UpdateCallback from BiomeFinder v1.2.9 which is not a depend, softdepend or loadbefore of this plugin.

The problem here is two plugins shading the same classes without relocating them. This works in 99% of cases but there is a small chance of it causing bugs (mostly with large dependencies) because of Bukkit's lax approach to accessing classes from every which where.

Thank. I will do the needful.

Yes all those warnings look valid to me and are unique.
Note that it is simply that, a warning, behaviour is not changed in any way.

The affected plugins need to add (soft)depends to their plugin.yml, or fix their code.

eg the very first one looks like a plugin bug, ForceResourcepacks accidentally imported the WorldEdit Location class rather than the Bukkit one. I doubt a plugin called ForceResourcepacks needs WorldEdit. Nevermind looks like it actually does.

Another one, eg xRay is just missing a depend – the plugin needs ProtocolLib but doesn't (soft)depend on it.

Jenkins 2596 reduced the number of WARN messages on my test server from 110 to 36 (152 plugins currently in the test bed, many bleeding-edge dev versions). Are these issues that need to be addressed by plugin developers? If so, I will post issues to them.
```
[22:03:01] [Server thread/WARN]: [ForceResourcepacks] Loaded class com.sk89q.worldedit.util.Location from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:03:02] [Server thread/WARN]: [WorldEdit] Loaded class net.milkbowl.vault.permission.Permission from Vault v1.7.3-b${env.TRAVIS_BUILD_NUMBER} which is not a depend, softdepend or loadbefore of this plugin.
[22:03:03] [Server thread/WARN]: [Vault] Loaded class com.earth2me.essentials.api.Economy from Essentials v2.17.1.53 which is not a depend, softdepend or loadbefore of this plugin.
[22:03:03] [Server thread/WARN]: [LuckPerms] Loaded class net.milkbowl.vault.permission.Permission from Vault v1.7.3-b${env.TRAVIS_BUILD_NUMBER} which is not a depend, softdepend or loadbefore of this plugin.
[22:03:30] [Server thread/WARN]: [xRay] Loaded class com.comphenix.protocol.wrappers.WrappedBlockData from ProtocolLib v4.5.1-SNAPSHOT-b445 which is not a depend, softdepend or loadbefore of this plugin.
[22:03:31] [Server thread/WARN]: [CoreProtect] Loaded class com.sk89q.worldedit.extent.Extent from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:03:31] [Server thread/WARN]: [DeluxeMenus] Loaded class net.milkbowl.vault.economy.Economy from Vault v1.7.3-b${env.TRAVIS_BUILD_NUMBER} which is not a depend, softdepend or loadbefore of this plugin.
[22:03:33] [Server thread/WARN]: [Plan] Loaded class javax.inject.Provider from SignEdit v1.10.2 which is not a depend, softdepend or loadbefore of this plugin.
[22:03:34] [Server thread/WARN]: [Plan] Loaded class me.konsolas.aac.AAC from AAC v4.3.5 which is not a depend, softdepend or loadbefore of this plugin.
[22:03:34] [Server thread/WARN]: [Plan] Loaded class com.earth2me.essentials.Essentials from Essentials v2.17.1.53 which is not a depend, softdepend or loadbefore of this plugin.
[22:03:34] [Server thread/WARN]: [HolographicExtension] Loaded class com.comphenix.protocol.events.PacketListener from ProtocolLib v4.5.1-SNAPSHOT-b445 which is not a depend, softdepend or loadbefore of this plugin.
[22:03:36] [Server thread/WARN]: [Denizen] Loaded class com.freneticllc.freneticutilities.freneticdatasyntax.FDSSection from Sentinel v2.0.1-SNAPSHOT (build 336) which is not a depend, softdepend or loadbefore of this plugin.
[22:03:37] [Server thread/WARN]: [ExtraContexts] Loaded class com.sk89q.worldedit.world.World from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:03:37] [Server thread/WARN]: [Multiverse-Core] Loaded class net.milkbowl.vault.economy.Economy from Vault v1.7.3-b${env.TRAVIS_BUILD_NUMBER} which is not a depend, softdepend or loadbefore of this plugin.
[22:04:09] [Server thread/WARN]: [Multiverse-Portals] Loaded class com.sk89q.worldedit.IncompleteRegionException from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:04:11] [Server thread/WARN]: [BiomeRemap] Loaded class me.clip.placeholderapi.expansion.PlaceholderExpansion from PlaceholderAPI v2.10.5-DEV-84 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:11] [Server thread/WARN]: [PhatLoots] Loaded class net.citizensnpcs.api.event.NPCSpawnEvent from Citizens v2.0.26-SNAPSHOT (build 1815) which is not a depend, softdepend or loadbefore of this plugin.
[22:04:12] [Server thread/WARN]: [CombatLogX] Loaded class world.bentobox.bentobox.BentoBox from BentoBox v1.11.1-SNAPSHOT-b1628 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:13] [Server thread/WARN]: [MobHunting] Loaded class org.inventivetalent.update.spiget.UpdateCallback from BiomeFinder v1.2.9 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.earth2me.essentials.Essentials from Essentials v2.17.1.53 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.onarandombox.MultiverseCore.MultiverseCore from Multiverse-Core v4.1.1-SNAPSHOT-b777 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.hmmcrunchy.thirst.Thirst from Thirst v2.10.0 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.hmmcrunchy.disease.Disease from Disease v3.3.0 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class ch.njol.skript.Skript from Skript v2.4.1 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class net.milkbowl.vault.economy.Economy from Vault v1.7.3-b${env.TRAVIS_BUILD_NUMBER} which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.vk2gpz.coordinatetool.CoordinateTool from CoordinateTool v2.1.1 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class me.blackvein.quests.Quests from Quests v3.8.5-b64 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class net.luckperms.api.LuckPerms from LuckPerms v5.0.70 which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.sk89q.worldguard.WorldGuard from WorldGuard v7.0.3-SNAPSHOT;2015-637665f which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [PlaceholderAPI] Loaded class com.sk89q.worldedit.world.World from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [BentoBox] Loaded class com.sk89q.worldedit.WorldEdit from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [Skript] Loaded class com.sk89q.worldguard.WorldGuard from WorldGuard v7.0.3-SNAPSHOT;2015-637665f which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [Skript] Loaded class com.sk89q.worldedit.math.BlockVector3 from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
[22:04:15] [Server thread/WARN]: [Skript] Loaded class net.milkbowl.vault.economy.Economy from Vault v1.7.3-b${env.TRAVIS_BUILD_NUMBER} which is not a depend, softdepend or loadbefore of this plugin.
[22:04:19] [Server thread/WARN]: [Builder] Loaded class net.citizensnpcs.api.CitizensAPI from Citizens v2.0.26-SNAPSHOT (build 1815) which is not a depend, softdepend or loadbefore of this plugin.
[22:04:21] [Server thread/WARN]: [PhatLoots] Loaded class com.sk89q.worldedit.bukkit.BukkitAdapter from WorldEdit v7.1.1-SNAPSHOT;4828-e5c3c7a which is not a depend, softdepend or loadbefore of this plugin.
```

Right, looks like there was a bug where the second plugin displayed was wrong.
I've also limited to message to once per plugin/depend pair rather than class

Jenkins 2595

Those examples look like they are from an outdated build.