Open blubberdiblub opened 7 years ago
For easier viewing, the end of the log, where the exception is thrown, is this:
[12:19:22] [main/ERROR] [LaunchWrapper]: Unable to launch
java.lang.ClassNotFoundException: org.spongepowered.server.SpongeVanillaLauncher
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:191) ~[launchwrapper-1.12.jar:?]
at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_121]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_121]
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_121]
at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_121]
at net.minecraft.launchwrapper.Launch.launch(Launch.java:131) [launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.Launch.main(Launch.java:28) [launchwrapper-1.12.jar:?]
at org.spongepowered.server.launch.VanillaServerMain.main(VanillaServerMain.java:118) [server.jar:1.11.2-6.0.0-BETA-216]
at org.spongepowered.server.launch.VersionCheckingMain.main(VersionCheckingMain.java:38) [server.jar:1.11.2-6.0.0-BETA-216]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_121]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_121]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
at StartServer.main(StartServer.java:24) [start/:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_121]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_121]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_121]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_121]
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147) [idea_rt.jar:?]
Caused by: java.lang.NoSuchMethodError: org.objectweb.asm.Handle.isInterface()Z
at org.objectweb.asm.commons.Remapper.mapValue(Unknown Source) ~[server.jar:1.11.2-6.0.0-BETA-216]
at org.objectweb.asm.commons.MethodRemapper.visitInvokeDynamicInsn(Unknown Source) ~[server.jar:1.11.2-6.0.0-BETA-216]
at org.objectweb.asm.ClassReader.a(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.b(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.accept(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
at org.objectweb.asm.ClassReader.accept(Unknown Source) ~[asm-5.0.3.jar:5.0.3]
at org.spongepowered.server.launch.transformer.deobf.DeobfuscationTransformer.transform(DeobfuscationTransformer.java:80) ~[server.jar:1.11.2-6.0.0
at net.minecraft.launchwrapper.LaunchClassLoader.runTransformers(LaunchClassLoader.java:279) ~[launchwrapper-1.12.jar:?]
at net.minecraft.launchwrapper.LaunchClassLoader.findClass(LaunchClassLoader.java:176) ~[launchwrapper-1.12.jar:?]
... 18 more
Did you refresh gradle in the gradle menu?
You mean the "Refresh all Gradle projects" button, right? I'm using that one all the time, hoping it will fix something, but to no avail.
The "Synchronize 'ProjectName'" item in the Project Navigator doesn't help, either.
Also, redoing the "setupServer" task (which is from SpongeStart) doesn't fix the problem for me.
Note that StartForgeServer works, it's just StartVanillaServer that doesn't. Of course, that doesn't completely rule out that I'm doing something wrong. So if you have any hints as to what I could do or how I could debug that, I'd be grateful.
What I think is that the "objectweb" dependency has "compile" scope. What means their are 2 of those available at runtime. Could you verify that all the sponge API dependencies are set to "provided"? Normally my plugin tries to take care of that, but sometimes fails doing so. You should be able to see that in the gradle menu.
Sure, if I can figure out how to do that ;) (I'm navigating on foreign waters here). I made a screenshot in the hopes that it contains what you like to see:
When running ./gradlew dependencies
on the command line, it also fails partially (just a snippet showing the end of the output):
Task :dependencies class loader hash: 01d9458a7e5b59caccdb01424c57a842
Task :dependencies actions class loader hash: 18198991b357e4282b88db10fdb1e992
:dependencies (Thread[Daemon worker Thread 4,5,main]) completed. Took 0.085 secs.
BUILD SUCCESSFUL
Total time: 0.603 secs
Stopped 0 worker daemon(s).
Received result Failure[value=org.gradle.api.InvalidUserDataException: Cannot change dependencies of configuration ':spongeStart_Provided' after it has been resolved.] from daemon DaemonInfo{pid=21475, address=[dbb9ce6b-a87c-4acb-a04f-a2e7cbf047ad port:42443, addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Idle, lastBusy=1486654849151, context=DefaultDaemonContext[uid=80cd6777-03f6-42f0-a5a4-bfdd3a12ba9b,javaHome=/usr/lib/jvm/java-8-openjdk-amd64,daemonRegistryDir=/home/nboehm/.gradle/daemon,pid=21475,idleTimeout=10800000,daemonOpts=-XX:MaxPermSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xmx1024m,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant]} (build should be done).
FAILURE: Build failed with an exception.
* What went wrong:
Cannot change dependencies of configuration ':spongeStart_Provided' after it has been resolved.
However, I have no idea whether that's related or not.
Looks like something is wrong. I be home in 2 hours and than I can take a quick look at it.
I tried to reproduce this and it works fine for me.
My guess is that your gradle version might be outdated, I am using version 2.13.
Well, it's 3.3 here, so maybe the other way round?
I'm using the gradle wrapper version that lives directly inside the project folder. The package that comes with my OS (version 3.2.1, btw) failed on some ready-made build.gradle
files I tried recently, so I gave up on that one.
(Ubuntu Zesty Zapus here)
Actually, the gradle package that comes with Zesty Zapus fails on some library mismatch, which is not unexpected, as Zesty hasn't been released yet ;)
So what I did now is downgrade the gradle package to 2.13-4 and also the dependent packages which it required an older version for - up to the point that gradle was working again. And I deleted all gradle and maven caches. That resulted in gradle build
working again and gradle dependencies
now completing without failure.
However, IDEA was stubbornly reporting problems now. So I deleted everything except the source code and the gradle scripts. Then I reimported the project.
And lo-and-behold, StartVanillaServer
was working now, too.
So it appears that it really might be a gradle version problem. - SpongeStart might not be fully compatible with gradle 3.3, yet.
However, I do not want to keep those Yakkety packages on my Zesty install, especially as I would have to pin all of those dependencies (mainly library packages) where the old gradle cannot tolerate a newer version. So I'll go back to gradle 3.3, even if that means I cannot use the StartVanillaServer
run configuration for now.
On the plus side, I'll clean out the project one more time and reimport it again and we'll see whether some unclean project state might have caused the problem in the first place.
I tried with gradle wrapper 3.2.1 and 3.3 on a freshly imported project, and both StartVanillaServer
and ./gradlew dependencies
fail as described above.
So we can be pretty sure now it's related to the gradle version.
And as I'm using the gradle wrapper, I figured that I can just use version 2.13 locally in the project without affecting the rest of my system (of course, I should have thought of that earlier, before doing the Package Fandango), so I will go with that for the time being.
@blubberdiblub I'll take a look at this in a few hours. Will update when I find something relevant.
@blubberdiblub @thomas15v As far as I can tell, this isn't a gradle issue.
The bug is reproducable using my own code:
public static void main(String[] args) throws IOException, ClassNotFoundException, NoSuchMethodException, InvocationTargetException, IllegalAccessException {
final Path vanillaPath = Paths.get("").resolve("server.jar");
final Manifest manifest = new JarFile(vanillaPath.toFile()).getManifest();
final SpongeClassLoader loader = new SpongeClassLoader(new URL[]{vanillaPath.toFile().toURI().toURL()}, TestMain.class.getClassLoader());
loader.loadClass(manifest.getMainAttributes().getValue("Main-Class")).getMethod("main", new Class[]{String[].class}).invoke(null, new Object[]{args});
}
I'm not sure as of yet why it seems adjusting the Gradle version fixes this issue (according to reports above - I haven't tried myself), as my reproducing this error has nothing to do with Gradle.
I will tweak the above until I have a working solution.
So... I retract my earlier statement.
It's most definitely a Gradle issue. However - it's not a problem with SpongeStart, so far as I can tell.
The code which is causing the issue (posted above) isn't part of SpongeStart's gradle task. It's entirely separable and can be run as it's own program.
http://i.imgur.com/aVTVqDb.png
I'm not exactly sure HOW Gradle is interfering, but downgrading does in fact fix the problem.
I downgraded Gradle to 2.13, refreshed and restarted everything. It still gives me the same error.
Same error on Gradle 3.5 or 3.6-snapshot.
Same issue on Gradle 3.4.1
Running the Vanilla Sponge from IDEA fails for me whereas running SpongeForge works fine.
The only differences in the run configurations are the working directory (
run/forge
vs.run/vanilla
) and the-scan-classpath
argument, but removing that argument from the StartVanillaServer configuration doesn't help, either.See the attached log output.
The possibly interesting parts of my
build.gradle
are: