I’ve been tooling around with this for the last day or so to see about which way seemed easiest to get Spigot into the webui. I’d been putting this off for so long because multi-step profiles I knew would take a lot of work–and now I feel suitably ready that I have the time for it.
I took your second approach, which was to create a second page. It’s still in heavy dev, but I’ve actually gotten to build the spigot and craftbukkit jars entirely from the webui. This isn’t to say the workflow is finalized or that it is the best possible approach, but it is the approach that made the most sense to me, while trying to keep the number of code changes minimal–and keep it to mostly code addition.
Feel free to look at it here: https://github.com/hexparrot/mineos-node/tree/spigot_profiles
The general idea of what changes I made are these:
- profiles continues to be an automatically generated and grouped list of software
- the buildtools jar, which updates often, operates like the rest of the profiles; you download it and it puts it in a
/var/games/minecraft/profiles/Buildtools-45directory - The new page (currently called buildtools, but wouldn’t stay that way) partitions off all the new functionality. In this way, profiles have no immediate changes either to the webui design or the backend.
- The buildtools page has a dropdown to select the buildtools jar you wish to use. In almost 100% of cases, the user should be expected to use the most recent one, but I still leave it as a step for the user currently
- The buildtools page actually taps into the onscreen output of
BuildTools.jar. There’s so many places that the building can go wrong, that this was unavoidable. There’s an upside (25 lines of actual information) and a downside (this uses just an unbelievable amount of bandwidth). - In its current state, it’s still lacking. The files themselves are created in the webui but aren’t moved to the server’s live directory, which is what I’ll be working on next. I’m still trying to come up with a clean way to do this.
Note, I created this branch to help move in the direction of your stated goal, but not to discourage you from your own designs. You are more than welcome to use any of the code I’ve created if you feel that there is something fundamentally improve-able over my choices here, or you may simply wait for me to develop this in entirety.
I have visualized in my mind the appropriate way that these files will be moved over to the right place strictly from the webui and I think I’ll have a working model by the end of the day. I encourage you to give the branch a shot at some point to see if this workflow is intuitive for you and all users who you will be sharing your webui with.