Closed freeze-dolphin closed 3 years ago
Are you sure the version of Scala in your build.sbt/pom.xml is the same as the version used in the @Scala
annotation on your main class?
Because I'm not able to reproduce this. You're getting a NoSuchMethodError (indicating that a method doesn't exist), but you didn't get a NoClassDefFoundError (indicating that a class doesn't exist), so the Predef object has been found by the classloader.
It seems pretty much impossible that the ScalaPluginClassLoader cannot find classes from the Scala standardlibrary, because the parent classloader is the ScalaLibraryClassLoader which has access to those classes.
If you can give a minimal example of your code (either in source, or packaged as a jar) then I can debug this, but I have no place to start at this point.
One other thing you can do is to execute the command /listscalaplugins
which will output the version of Scala used by each plugin at runtime. For the ScalaExample en Scala3Example plugin this looks as follows:
This means that both plugins use the 'compatibility release version 3.0.x', (which is binary compatible with 2.13.x), and the versions of scala in their definitions are 2.13.6 and 3.0.1 respectively. ScalaLoader will always pick the latest version of the library to load plugins that use compatible versions, so in this case the ScalaExample plugin is getting the 3.0.1 library.
/listscalaplugins
, which showed me:
[17:43:21 INFO]: === ScalaPlugins by major Scala version ===
[17:43:21 INFO]: [2.13.x] PlainShop (2.13.6)
I would appreciate it if you could help me with this problem!
Alright I cloned it, replaced the ink.ptms.core dependency by the official spigot server dependency (you're not trying to supply-chain-attack me here, are you?) and got it to compile. I will investigate later tonight. Feel free to make your repo private again.
Alright I cloned it, replaced the ink.ptms.core dependency by the official spigot server dependency (you're not trying to supply-chain-attack me here, are you?) and got it to compile. I will investigate later tonight. Feel free to make your repo private again.
Actually this is a modified paper core, I have asked the maintainer what's the differences between this and the official spigot core. And here is the original thread url: Note that you may need a translator to read this, which is in Chinese
Also, from his words, I may know the reason why it always shows me this error!
Also, from his words, I may know the reason why it always shows me this error!
Well, it seems that this error still remains after replacing ink.ptms.core into the official spigot core.
Well, it seems that this error still remains after replacing ink.ptms.core into the official spigot core.
Yes I know. I didn't say it was part of the solution, but I just didn't want to have a dependency from a http repository. A "supply chain attack" is an attack where a system gets compromised by compromomising trusted sources. I don't trust maven artifacts from a http repository because some man in the middle could change the bytecode in the jar file and potentially compromise my computer if I were to execute code from that custom fork of paper.
I'm really tired now actually, I'll have to dig into this some other time.
But the way, this error occurs while performing command /plainshop opn
.
If you want to try this plugin on your local server, you need to perform /plainshop crt
to create a category first and then do opn
.
Alright, thanks!
I have solved this by myself, thank you for your concern!
If you did this by changing the code of ScalaLoader, then I would very much like to have your patch and include it in the project under the LGPL v3 license.
Problems
I use
ScalaPluginLoader
in order to avoid packaging Scala libraries into my plugins, but it still threw aNoSuchMethodError
like this:Codes at UIUtl.scala:43: