[solved] Why compile Spigot?

Discussion in 'Spigot Discussion' started by omgitsjayden, Feb 3, 2020.

Thread Status:
Not open for further replies.
  1. seems dumb. why not just let people download the JAR that gets exported from [insert IDE here]?

    craftbukkit, mojang, and paper let us do this.
    so does waterfall (which is a paper fork for bungeecord), and sponge.
     
  2. Remember the Bukkit DMCA? Nobody is allowed to redistribute the source code of Mojang. If they put the source code available for download in a Jar, it's considered redistributing. BuildTools, what you use to build Spigot, is a hacky workaround to build the code locally, thus avoiding the "redistributing" part, since the Mojang code itself isn't actually redistributed directly. It's hacky, but it works I guess. It downloads the official server Jar, decompiles it, does a bunch of magic on it, and eventually poops out Spigot.

    Just because you can find it somewhere doesn't mean it's legal. Mojang redistributes their own software. Pretty sure Craftbukkit falls under "their software" nowadays. Paper, not sure, they probably don't care or it's some detail I'm missing.

    Bungeecord is merely a proxy, to my knowledge it does not use any of the original Minecraft servers code, so it doesn't fall under the problem of it accidentally redistributing Mojangs code. Don't know about Sponge, never touched it.
     
    • Like Like x 2
    • Agree Agree x 1
  3. To add to this. CraftBukkit has no official downloads anywhere. Only legal way to get it is via build tools as MrDienns said
    As for Paper, you also can't download a paper jar. The jar you download from them is a patcher, and in a sense does the same thing as build tools does. It downloads the Minecraft jar from Mojang, patches it and creates a new jar (called patched_version_here.jar in the cache folder)
     
  4. I'm OK with the BuildTools process. I run a custom log4j2.xml file, so my bat file which runs BuildTools also inserts my log4j2 file into the Spigot jar automatically. I just wish there was an easier way to see if it's up to date than running /version in the console or in-game.
     
  5. You can use a shell script (batch script) that can check online for the version you're using, and if there's a new buildtools and new spigot release out .. then only update when it's needed. You can run this manually. This way you don't poke the site more than needed, you don't continuously download the same jar for buildtools, and only run it if there's a new spigot out to make.

    Using parameters you can check if you just get the latest recommended, so it changes to 1.16 you get 1.16.jar as well. Or if you force it to something, and use --rev 1.15.2 for example, to get the latest available build for 1.15.2

    The shell script can be made just how you want it, of course, doesn't have to be dynamic.

    And you can even run it on a scheduler like linux's crontab or startup service, or whatever windows might have. And have it report back if there's a new jar to test (heck, it can even clone your live site, do some magic to it to set a new port and what not) so you can test it before going live (least downtime)

    Anyway, .. it's then just a one liner like "makenewspigot.bat" or "dothebuildtoolsmagic.sh"

    no different than getting the latest paper and popping that in a dir and all that stuff.

    using shell you can also tell it which version compiles with what, like java 7 for 1.8 or java 8 for 1.12 or java 11 for 1.15.2 etc. whatever you want.

    some urls you can use to compare stuff against, might be helpful for automating things
    Code (Text):

    https://hub.spigotmc.org/stash/projects/SPIGOT/repos/builddata/raw/info.json
    https://hub.spigotmc.org/versions/1.15.2.json (can be dynamic $mc_version)
    https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/buildNumber
    https://hub.spigotmc.org/jenkins/job/BuildTools/lastSuccessfulBuild/artifact/target/BuildTools.jar
     
    for example, just running a script i wrote i can start fresh (removed cache first, then let the script figure the rest out)
    [​IMG]

    but then later, if there is already a jar, our cache file knows what we have locally .. it will check, but not download buildtools and not use it to compile spigot (since the version comparison say both are 100% match)
    [​IMG]

    Anyway, what i am trying to say is: paper is nice, that you can just drag and drop - after a download, and run that, and it will figure it out for you .. sure, but it's not really too hard to get buildtools either, and let that figure out spigot for you - and then use that.

    (this post is basically a reply to bob, and op)
     
  6. Too bad a build string of some sort isn't available through the query interface.

    Hey, a related question: Is it safe to upload the new Spigot .jar file while the server is running, then simply restart the server? I believe its running Ubuntu, if that matters. (I've been doing stop - upload - start.)
     
  7. I've done that with plugins a few times and it did result in some errors. If there's a proper way of doing it, I'm curious.
     
  8. The way to do it with plugins is to upload the new jar file(s) to plugins/update, then restart the server. It will automatically move the files to the plugins directory when the server restarts. (Only does it for existing plugins, not new ones. New ones can go directly into plugins anyway.)

    But I don't know if the main Spigot .jar file is locked or open while the server is running.
     
  9. electronicboy

    IRC Staff

    On windows, no; On any sane *nix platform, just delete the jar before you replace it; For plugins specifically, there is the plugins/update folder, which will let you place jars in there with the same name as that of your plugin folder and it'll copy them out before it loads plugins
     
    • Informative Informative x 3
  10. don't replace and then stop, /stop first, then handle the jar files, and start things.
    Handling includes backing up properly.

    We use a /queue/ directory and a shell script that handles things before starting.

    We don't replace on the live server until we're finished testing on the test/ server first.
     
  11. You still can't do that tho. Java classloader will refuse to load any new classes from deleted/replaced jar. So if you had some classes from spigot that weren't loaded yet, but are still needed, just sometimes, things gonna explode.
     
  12. ah so it's due to legal issues.

    makes sense.

    wish my compoopter didn't take half an hour to compile it (stupid thing).

    Thanks everyone!
     
    • Like Like x 2
Thread Status:
Not open for further replies.