-
Notifications
You must be signed in to change notification settings - Fork 11
How CraftBoot works
If you are making modifications to CraftBoot, you might find it useful to have a summary of how CraftBoot actually works. I tried to include lots of comments in the source code, but I always skimp or forget to be thorough enough, so here's this instead.
When you start CraftBoot for the first time, it creates a folder called ".craftboot" in your user home folder (on Windows, for example, this is something like "C:\Users\oxguy3\.craftboot\"). It then creates a sub-folder of ".craftboot" with the same name as the jar file CraftBoot is running from (so if you're running somefilename.jar, the folder will be ".craftboot\somefilename.jar\"). It then sends a request to http://oxguy3.github.io/craftboot-files/launcher/latest to find out the URL of the packed launcher jar. It then downloads the launcher from that URL, unpacks it, and puts it in a sub-folder called "launcher" with the current Unix timestamp as the filename.
After the user enters the URL for the launcher.properties file, it saves that URL to a file called ".craftbooturl" in the jar-named folder and downloads the launcher.properties file from that URL to the same folder. It then puts the file address of the launcher.properties file into a system property called "com.skcraft.launcher.propertiesFile" and starts up the launcher.
When you run CraftBoot again after you've previously set it up, it will run somewhat similarly. However, it will not download any updates to the launcher, but instead merely check if the launcher itself has downloaded any updates to the "launcher" folder. It will also re-download the launcher.properties file from the URL it was given on the initial setup (unless it can't load the page from the URL) before starting up the launcher again.
I didn't write the launcher, so I can't explain everything about it, but I can include the parts relevant to making a bootstrapper for it.
The launcher starts when the main(String[]) method is called in com.skcraft.launcher.Launcher. It will accept any of the command flags specified in com.skcraft.launcher.LauncherArguments. At time of writing, there are three:
- --dir: Specifies the directory that the launcher will store all its files in (if not specified, the launcher will use the directory where its stored)
- --bootstrap-version: Presumably meant to denote the protocol version of the communication between the bootstrapper and the launcher (i.e. these command flags). At present, the value is used for nothing more than printing a line to the console log. Nonetheless, this flag should be set to "1" so that the future versions of the launcher know how to respond if the protocol version should ever increment.
- --portable: This value is a boolean, but I don't know anything else about it because I found everything worked perfectly without having to set this.
Later in the startup process, the Launcher class configures its properties file with the statement:
this.properties = LauncherUtils.loadProperties(Launcher.class,
"launcher.properties", "com.skcraft.launcher.propertiesFile");
That last parameter, "com.skcraft.launcher.propertiesFile", specifies the name of a system property (i.e. System.getProperty(String)
) which, if set at all, should contain a file address pointing to a launcher.properties file.
So when LauncherUtils.loadProperties(Class<?>, String, String) runs, it creates an instance of Java's native Properties class and loads it with the launcher.properties file that comes packaged in the launcher jar. After it does that, it loads the launcher.properties file specified by the aforementioned system property. Because it is loaded into the same Properties object, it will override any values set in the original packaged launcher.properties file. This is essential to CraftBoot's launcher.properties downloading functionality.
Later in the booting process, the launcher downloads a bit of JSON from whatever selfUpdateUrl
is set to. This JSON file includes the URL of a packed jar of the current launcher version and the current version number; it looks something like this. If the version number in the JSON indicates that the launcher is outdated, it will show the user an "Update launcher" button. If the user clicks that button, it downloads the launcher exactly the same way that the bootstrapper does: by unpacking it and placing it in the launcher sub-folder with the timestamp for a filename.