OoliteStarter

[MrFlibble]

This is the currently stable one:
https://github.com/OoliteProject/Oolite ... ag/v0.1.31

I think if you stick to the builds on the master branch it would be fully sufficient. Experimental versions all have a branch name, as currently 'gelsemium'.

Cool. I cheated, 'cos I skipped the Maven headache by re-using the jar from the generic dist. I've managed to knock together a build script that does it all with little editing. Should be able to repeat this by just changing the version number.

Here's the app, simply zipped.
OoliteStarter-0.1.31-MacOS-x86_64.zip (56.96 MB)
And here, wrapped up in an installer.
OoliteStarter-0.1.31-x86_64.pkg (56.67 MB)

Thank you! I cannot check the content, but I added them to the stable release.

These uploads will self-destruct on July 12th at about 22:22.

Ummmm - I hope I understand the scope right...

Edit: I had failed to get maven build working due to

Code: Select all

src/test/java/oolite/starter/OoliteTest.java:        command.add("/usr/bin/ls");

/bin and /sbin were traditionally the home of stuff needed to boot the system and effect simple repairs before even mounting /usr (which might have been an NFS share).
It's ONLY at the more standard /bin/ls on the Mac. Most Linuxes these days assume a largely flat filesystem, with a symlink /usr/bin to /bin so 'ls' appears in both places.
IMHO, /bin/ls is a more robust choice. I've patched around it in my MacOs-x86_64 build script with sed, and can now build from scratch in one hit.

Ok, that unit test is no good choice. I just checked, and on Ubuntu ls is in the path I gave. But you are right, /bin is a symlink to /usr/bin so I can follow your suggestion.

All I need to do is edit the version number. Output files in $HOME/starter/build/target. I've pasted the build script below in case I have a nasty run in with the 'goids.

Code: Select all

#!/bin/bash

distVER=0.1.31
arch=x86_64

#Builder for Mac.
distURL=https://codeload.github.com/OoliteProject/OoliteStarter/zip/refs/tags/v$distVER
builddir=$HOME/starter/build

kaput(){ echo "$1" ; exit 2 ; }

[ "x$distVER" = "x" ] && kaput "Version is nonsense"
#jpackage won't accept the first digit of version being zero.
# so we patch it here.
MacVER=$(echo "$distVER" | sed 's@^0\.@1.@')

mkdir -p "$builddir" && cd "$builddir" || kaput "Can't make build dir $builddir"

getTar(){
	curl -L -o dist-${distVER}.zip $distURL
	unzip -qq dist-${distVER}.zip
	ls -al
}

doMaven(){
	#PATCH FOR MAC.
	#BSD sed insists on a suffix for backup when using -i to edit inline.
	sed -i flibble 's@/usr/bin/ls@/bin/ls@' \
 	 OoliteStarter-$distVER/src/test/java/oolite/starter/OoliteTest.java
	export PATH="$PATH:$HOME/maven/bin"
	cd OoliteStarter-$distVER || kaput "failed to cd to source" 
	mvn versions:set "-DnewVersion=$distVER"
	mvn -B package -e --file pom.xml
	cd -
}

doBuild(){
echo "$distVER"
jpackage \
 --type app-image \
 --app-version $MacVER \
 --copyright Copyright \
 --description "OoliteStarter $distVER" \
 --name "OoliteStarter" --dest target/appimage \
 --temp target/oolite-starter-tmp --vendor "OoliteProject" --verbose \
 --icon OoliteStarter-$distVER/src/main/resources/oolite_logo.png \
 --input OoliteStarter-$distVER/target/dist \
 --main-jar OoliteStarter-$distVER.jar \
 --main-class oolite.starter.MainFrame --mac-package-name "OoliteStarter" \
 --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
 --vendor OoliteProject
}

doApp(){
 jpackage \
  --type pkg \
  --verbose \
  --app-version $MacVER \
  --app-image target/appimage/OoliteStarter.app \
  --name "OoliteStarter" \
  --icon OoliteStarter-$distVER//src/main/resources/oolite_logo.png \
  --dest target \
  --resource-dir OoliteStarter-$distVER/src/jpackage/resources-mac \
  --vendor OoliteProject
}

makeZipDist(){
 cd target/appimage
 zip -qr ../OoliteStarter-${distVER}-MacOS-$arch.zip  *
 cd - ; cd target
 mv OoliteStarter-${MacVER}.pkg OoliteStarter-${distVER}-$arch.pkg
}

getTar
doMaven
doBuild
doApp
makeZipDist

Let's add that to the project. Just give it a meaningful name, add comments inside what it intends to do and stuff it besides pom.xml. I'm happy to accept a pull request.
Obviously I will never run that script, so maintenance is on you.

Responsibility.. erm.. yay!

That can be trivially tweaked to take args or env vars for arch and version, then it could reduce the github deps by just a ton. If devs can roll their own binaries to test, and the yaml stuff is simplified to-boot, surely life is better.