Change launcher to Idea's jar launcher

[randombyte-developer]

SpongeForge version: 1.11.2-2227-6.0.0-BETA-2260
SpongeStart version: 1.6.2
Gradle version: 3.1

When running the generated run configuration for the forge server: https://pastebin.com/XMjHmaXt

[thomas15v]

Urgh I really should change to the idea jar launcher (which I might since the current method has to may problems) . It also looks like their are sponge dependencies marked as compile in your classpath.

[randombyte-developer]

You can basically take any of my recent updated plugins and test.
Example plugin: https://github.com/randombyte-developer/easy-tellraw/blob/master/build.gradle (will release it today)
Using sponge vanilla #1 happens. Using sponge forge (for 1.11.2) the error above happens. The current workaround is(as you can see in the build file) using sponge forge for 1.10.

[thomas15v]

Yeah I bet the kapt "org.spongepowered:spongeapi:5.1.0" is messing it up. Since the plugin will look in the compile scope to remap all the dependencies to provided.

The way I code most of my plugins atm is with the following.
When I press "start server" the following happens:

1. Idea runs a task build plugin
2. The task packages the plugin and copies the jar to the plugins folder
3. Idea starts it's jar launcher which launches the server.

This does have some downsides:

• You have to build your plugin for each run. But android development is also done this way so it shouldn't be such a pain.
• Your plugin runs in an obfuscated environment which might make debugging more troublesome.

Positive things are:

• No need for a custom launcher class
• More guarantees that it actually will work (no more fiddling with gradle)
• Supports mixin plugins (with the current setup this doesn't work)

I don't know if this would be a good idea for SpongeStart tho. So what do you think? Scratch this messy classlauncher and run it correctly?

[randombyte-developer]

You have to build your plugin for each run. But android development is also done this way so it shouldn't be such a pain.

Doesn't bother me, the compiler is fast, especially with Kotlin's incremental compilation.

Your plugin runs in an obfuscated environment which might make debugging more troublesome.

Do you mean that NMS is obfuscated? It was anyway with SpongeStart. This didn't bother me, too.

• No need for a custom launcher class
• More guarantees that it actually will work (no more fiddling with gradle)
• Supports mixin plugins (with the current setup this doesn't work)

Well, good. 👍

---

I changed kapt to compile and it is still the same error. Doesn't matter since I use a forge server for 1.10.2.

I am looking forward to the a new SpongeStart! Is there anything I could help with?

[thomas15v]

I am looking forward to the a new SpongeStart! Is there anything I could help with?

Wel to make this it is fairly simple:

• We need is an extra gradle task: "buildplugin" that inherits from the build task and just copies the plugin to the correct folder. (with option to overwrite the files being copied)
• The next tricky part will be detecting dependency plugins and also copy those over.
• Modifying the run configuration to run the gradle task first and than just java -jar server.jar
• As last piece rip out everything related to the old configuration

[randombyte-developer]

Wait, code hotswapping won't be possible anymore, right? That would be really really sad...

[thomas15v]

No, hot swapping will still work.

[randombyte-developer]

Ok, but we are talking about building the plugin to a jar and then copying the jar to the mods folder?

[thomas15v]

Yes. But as far I understood IDEA launches the jar in its own kind of wrapper (in debug mode). Which has the ability to replace classes. Even if you aren't actually launching from these classes. So far I know the only requirements is that the name of the class is the same.

[randombyte-developer]

I can't find any documentation on 'IntelliJ jar launcher'.

[thomas15v]

Yeah: https://www.jetbrains.com/help/idea/2017.1/run-debug-configuration-jar-application.html.
It doesn't say anything about debugging. But I tested it before with noxray and it worked fine (not for mixins tho, but that is to be expected).

[randombyte-developer]

Are we going to directly manipulate the xml run configuration files? Like it is done now?

[thomas15v]

I am not really a fan of it. But apparently it works the best to solve the permission problems (although it makes zero sense to me).

[randombyte-developer]

How I fire up a test server:

1. Download SpongeVanilla/Forge to some run folder
2. New run configuration.
3. Main class: org.spongepowered.server.launch.VersionCheckingMain
4. VM options: -classpath path/to/project/run/vanilla/vanillaServer.jar:<otherStuff> where otherStuff is the whole classpath IntelliJ adds when I start a server with SpongeStart. I seems to include all the paths to the dependencies in jar form, e.g for the kotlin-stdlib: /home/randombyte/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.1.1/98e484e67f913e934559f7f55f0c94be5593f03c/kotlin-stdlib-1.1.1.jar.
5. Program args: --scan-classpath to make Sponge look for plugins in the classpath.
6. Hit run and it works flawlessly.

The cool thing about this is that the plugin isn't provided as a built jar but in form of the build folder. The otherStuff I mentioned also contains this: /home/randombyte/development/sponge/projects/holograms/build/classes/main.

Code hotswapping and debugging works.

The challenge is here to get the otherStuff. As I said I do this by running SpongeStart and then copying it. Can we somehow generate this classpath with all dependencies? It has like 25 entries.