OoliteStarter

General discussion for players of Oolite.

Moderators: winston, another_commander

User avatar
phkb
Impressively Grand Sub-Admiral
Impressively Grand Sub-Admiral
Posts: 4777
Joined: Tue Jan 21, 2014 10:37 pm
Location: Writing more OXPs, because the world needs more OXPs.

Re: Oolite Flavours

Post by phkb »

hiran wrote: Thu May 09, 2024 11:45 am
hiran wrote: Sun May 05, 2024 10:16 am
Please have a look at OoliteStarter v0.1.31-furbelow.2
@arquaebus @phkb: Have you had a chance looking at that new release? Are the issues you brought up covered, or is there further work necesary?
Sorry, just started a new job, so haven't had time. Should be able to have a look early next week.
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 279
Joined: Sun Feb 18, 2024 12:13 pm

Re: OoliteStarter

Post by MrFlibble »

Binary attempts were done first, but I'll show the 'other way' first as it actually seems to work quite easily:

Install Java SDK 17, I got it using the x86 dmg installer from this page https://www.oracle.com/uk/java/technolo ... jdk17-mac . The Arm version is there if using Apple silicon.

(Looks like java 17 is effectively obsolete after September. Do you know if it'll work with a more recent version? If so, we should edit this and recommend the newest version that will play nice.)

Get the generic tar.gz version from your releases page. Double click it to extract. A new folder will appear. Navigate into that folder. then either:
  • Best way: Make sure terminal is on your dock. Drag run.sh onto Terminal, hit return in Terminal.
  • Fluffiest way: Right click (or ctrl-click) the file run.sh, select Open-with, other application, enable 'all Applications', navigate to Applications/Utilities and select 'Terminal', if you set 'always' then double clicking any file with a .sh extension will invoke terminal and run it.
  • Another fluffy way. Navigate into 'dist' folder, right click the 'jar' file, and select open with JavaLauncher. It'll grumble that the app might be infested with malware, but you can overrule that.
I'll remind myself how to make a terminal launch 'properly fluffy' when I get time. I think there's a trivial way to make an app bundle directory with an icon and all. That may still end up with the java icon when handing off to java.

Ready to run versions:-

Testing the package on MacOS Ventura (13.6.7), Intel. I expect it to fail, as github is using Arm. I fell on the same spike with the other thing. Might be worth making that apparent on releases.

First attempt is with the gelsemium.2.pkg. The package manager whinges this:-
cannot be opened because it is from an unknown developer. macOS cannot verify that this app is free from malware.
I see you've commented that out in the build.yml. Have you not got valid keys to sign it? No biggie, as the user can just get the pkg from the zip...

The app from the zip fails thus:
You can't open the application "OoliteStarter" because this application in not supported on this Mac.
The info on that one shows it as "Apple silicon", ergo it's doomed to fail on intel.

I've had a nose at the build.yml and readme.md. I've grabbed Java 17 JDK and built it successfully on x86_64. I grabbed the source and dist and did a bit of renaming to botch it together. It moans about the png file not being icns format, so it's going to use the default. Looks ok though. Guess I need to install OoLite-dev mac x86_64 to see if it really-really works, though my 'Mac' is not a mac, and might not have the graphical oomph :wink:

There are some positive gruntings around the interwebs on how to do universal2 with jpackage. These two links may be helpful if you wanted to try it.
https://stackoverflow.com/questions/717 ... undled-jre
leads to these two:
https://github.com/ChristopherBruno78/universal_jre
https://incenp.org/notes/2023/universal ... macos.html

It may be kinder to make two flavours for macOS, x86_64 and arm_64 since the universal binary might weigh in at 300 megs!

Another horrible alternative is to make it x86_64 only, and use Rosetta to interpret it on arm. Not worth doing IMHO.

Seems a heck of a penalty, 150megs to get a nice icon, vs. ~10megs to just run it from .jar. Is there no way to embed a nice icon in a .jar?
User avatar
hiran
Theorethicist
Posts: 2266
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: OoliteStarter

Post by hiran »

MrFlibble wrote: Tue Jun 11, 2024 6:58 pm
Binary attempts were done first, but I'll show the 'other way' first as it actually seems to work quite easily:

Install Java SDK 17, I got it using the x86 dmg installer from this page https://www.oracle.com/uk/java/technolo ... jdk17-mac . The Arm version is there if using Apple silicon.

(Looks like java 17 is effectively obsolete after September. Do you know if it'll work with a more recent version? If so, we should edit this and recommend the newest version that will play nice.)
The documentation say OoliteStarter needs JDK 17+, so it should run smoothly on a newer version, e.g. 21.
According to my data OpenJDK 17 would enjoy support for at least one more year. See
- https://www.oracle.com/java/technologie ... admap.html
- https://access.redhat.com/articles/1299013

Nevertheless I just checked and upgraded the dependencies so new versions directly build on OpenJDK 21.
MrFlibble wrote: Tue Jun 11, 2024 6:58 pm
Get the generic tar.gz version from your releases page. Double click it to extract. A new folder will appear. Navigate into that folder. then either:
  • Best way: Make sure terminal is on your dock. Drag run.sh onto Terminal, hit return in Terminal.
  • Fluffiest way: Right click (or ctrl-click) the file run.sh, select Open-with, other application, enable 'all Applications', navigate to Applications/Utilities and select 'Terminal', if you set 'always' then double clicking any file with a .sh extension will invoke terminal and run it.
  • Another fluffy way. Navigate into 'dist' folder, right click the 'jar' file, and select open with JavaLauncher. It'll grumble that the app might be infested with malware, but you can overrule that.
I'll remind myself how to make a terminal launch 'properly fluffy' when I get time. I think there's a trivial way to make an app bundle directory with an icon and all. That may still end up with the java icon when handing off to java.
So no surprises here. That is good. :-)
MrFlibble wrote: Tue Jun 11, 2024 6:58 pm
Ready to run versions:-

Testing the package on MacOS Ventura (13.6.7), Intel. I expect it to fail, as github is using Arm. I fell on the same spike with the other thing. Might be worth making that apparent on releases.
What? Really? Indeed I never checked!
Here's an excerpt from the logs:

Code: Select all

Current runner version: '2.317.0'
Operating System
  macOS
  14.5
  23F79
Runner Image
  Image: macos-14-arm64
  Version: 20240603.1
  Included Software: https://github.com/actions/runner-images/blob/macos-14-arm64/20240603.1/images/macos/macos-14-arm64-Readme.md
  Image Release: https://github.com/actions/runner-images/releases/tag/macos-14-arm64%2F20240603.1
Oh no! And I teased poor Cholmondely... :oops:

While I don't know how to trigger an Intel 64 bit MacOS runner I will try to at least indicate something in the filename. What a bummer...
https://docs.github.com/en/actions/usin ... ed-runners
MrFlibble wrote: Tue Jun 11, 2024 6:58 pm
I've had a nose at the build.yml and readme.md. I've grabbed Java 17 JDK and built it successfully on x86_64. I grabbed the source and dist and did a bit of renaming to botch it together. It moans about the png file not being icns format, so it's going to use the default. Looks ok though. Guess I need to install OoLite-dev mac x86_64 to see if it really-really works, though my 'Mac' is not a mac, and might not have the graphical oomph :wink:
Wow, you got very far. So it all boils down to finding an Intel Runner in Github.


There are some positive gruntings around the interwebs on how to do universal2 with jpackage. These two links may be helpful if you wanted to try it.
https://stackoverflow.com/questions/717 ... undled-jre
leads to these two:
https://github.com/ChristopherBruno78/universal_jre
https://incenp.org/notes/2023/universal ... macos.html

It may be kinder to make two flavours for macOS, x86_64 and arm_64 since the universal binary might weigh in at 300 megs!

Another horrible alternative is to make it x86_64 only, and use Rosetta to interpret it on arm. Not worth doing IMHO.

Seems a heck of a penalty, 150megs to get a nice icon, vs. ~10megs to just run it from .jar. Is there no way to embed a nice icon in a .jar?
[/quote]
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.
And actually we are facing the same issue with the precompiled debug console. :roll:
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 279
Joined: Sun Feb 18, 2024 12:13 pm

Re: OoliteStarter

Post by MrFlibble »

hiran wrote: Tue Jun 11, 2024 8:05 pm
Wow, you got very far. So it all boils down to finding an Intel Runner in Github.
...
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.
I don't think there is one. Going the universal2 route may be do-able if using the universal2 version of java. If so, then building on Arm64 won't be a problem.

Else I can do a local build for you to manually upload to github release. It's a workaround. If it's only done on required releases, it's not a big bother.
hiran wrote: Tue Jun 11, 2024 8:05 pm
And actually we are facing the same issue with the precompiled debug console. :roll:
Yup. You can see I've stopped building it on my one for now. I found it's not quite working when I tested it, hence the delay. I'm trying to fix it on my x86_64 (with a bit of help from Cag!) before I worry about making binaries for MacOS. Same possible workaround, I may have to do that as a local build for intel Mac.
User avatar
hiran
Theorethicist
Posts: 2266
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: OoliteStarter

Post by hiran »

MrFlibble wrote: Tue Jun 11, 2024 8:23 pm
hiran wrote: Tue Jun 11, 2024 8:05 pm
Wow, you got very far. So it all boils down to finding an Intel Runner in Github.
...
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.
I don't think there is one. Going the universal2 route may be do-able if using the universal2 version of java. If so, then building on Arm64 won't be a problem.

Else I can do a local build for you to manually upload to github release. It's a workaround. If it's only done on required releases, it's not a big bother.
hiran wrote: Tue Jun 11, 2024 8:05 pm
And actually we are facing the same issue with the precompiled debug console. :roll:
Yup. You can see I've stopped building it on my one for now. I found it's not quite working when I tested it, hence the delay. I'm trying to fix it on my x86_64 (with a bit of help from Cag!) before I worry about making binaries for MacOS. Same possible workaround, I may have to do that as a local build for intel Mac.
Hmmm, building manually? I'd go mad with something like that.
But if you have the equipment, you could actually install the Github Runner software and use it as self-hosted runner. That would relieve you from building manually despite it would build on your computer.

Edit: Now I am thinking about the Oolite releases themselves. I never checked the MacOS architecture. That could be part of our problems. After all we try to link to precompiled shared libraries. Oh man...
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 279
Joined: Sun Feb 18, 2024 12:13 pm

Re: OoliteStarter

Post by MrFlibble »

hiran wrote: Tue Jun 11, 2024 8:37 pm
MrFlibble wrote: Tue Jun 11, 2024 8:23 pm
hiran wrote: Tue Jun 11, 2024 8:05 pm
Wow, you got very far. So it all boils down to finding an Intel Runner in Github.
...
Sounds good for me. Although I am not sure how to package that well without having the right runner. But if you can find out your input is definitely welcome.
I don't think there is one. Going the universal2 route may be do-able if using the universal2 version of java. If so, then building on Arm64 won't be a problem.

Else I can do a local build for you to manually upload to github release. It's a workaround. If it's only done on required releases, it's not a big bother.
hiran wrote: Tue Jun 11, 2024 8:05 pm
And actually we are facing the same issue with the precompiled debug console. :roll:
Yup. You can see I've stopped building it on my one for now. I found it's not quite working when I tested it, hence the delay. I'm trying to fix it on my x86_64 (with a bit of help from Cag!) before I worry about making binaries for MacOS. Same possible workaround, I may have to do that as a local build for intel Mac.
Hmmm, building manually? I'd go mad with something like that.
But if you have the equipment, you could actually install the Github Runner software and use it as self-hosted runner. That would relieve you from building manually despite it would build on your computer.
If I can boil the build process down to a script, it'll be no bother as all I'd have to do is boot it (remotely if I want), then launch the build script. Almost at that now. If that script (like builder on the other thing) can live in-tree, then others can roll their own variants by running a single script, or someone else can take over if I get shot down by pirates. Using my 'Mac' as a runner is probably not an option for a number of reasons.
arquebus
---- E L I T E ----
---- E L I T E ----
Posts: 518
Joined: Sun Oct 31, 2021 6:07 am
Contact:

Re: OoliteStarter

Post by arquebus »

Very weird things happening in gelsemium.4 regarding updated OXPs

I'm seeing multiple versions of the same OXP in my Installed list, but it's not clear in the UI whether they're all installed at the same time, or only the most recent. To be sure, I uninstall the older versions, which takes out ALL of the versions.

The bottom description section always says "install this as an update" regardless of the OXP's status (not installed, installed) except when it's the only version in the installed list (which happens if you uninstall the older one, which knocks all of them out, and then you re-install the one from the left side, which will always be the most recent).
Here is my YouTube channel, where I play poorly: Arquebus X
arquebus
---- E L I T E ----
---- E L I T E ----
Posts: 518
Joined: Sun Oct 31, 2021 6:07 am
Contact:

Re: OoliteStarter

Post by arquebus »

An additional glitch:

Right side, filter to Updatable

List contains OXPs that the description below says have newer versions.

Newer versions do not appear anywhere on the left screen. It is unclear how to update.

Galactic Registry (for example) is updatable from 5.8 to 5.9.1. Doesn't appear in left list. So I uninstall from the right to see if I can simply reinstall with the newer version... and it still doesn't show up on the left list. But then if I remove the filter (show all), there it is, updated.

So basically the interface does not explain how to update an OXP, but ends up updating the OXP anyway when you uninstall it. Which means that the uninstall arrow is actually an update arrow when you're filtered by updatable. Or something. Unclear.
Here is my YouTube channel, where I play poorly: Arquebus X
arquebus
---- E L I T E ----
---- E L I T E ----
Posts: 518
Joined: Sun Oct 31, 2021 6:07 am
Contact:

Re: OoliteStarter

Post by arquebus »

I renew my plea to at least have an option to automatically do all of this stuff in the background, with a summary notification of what was done.
Here is my YouTube channel, where I play poorly: Arquebus X
User avatar
hiran
Theorethicist
Posts: 2266
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: OoliteStarter

Post by hiran »

Can I replay the situation? After all I had not touched the OXP managing stuff for a few versions.

Regarding background updates: they are offered but with a screen to approve the activity before magick happens.
Sunshine - Moonlight - Good Times - Oolite
User avatar
hiran
Theorethicist
Posts: 2266
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: OoliteStarter

Post by hiran »

MrFlibble wrote: Tue Jun 11, 2024 8:42 pm
If I can boil the build process down to a script, it'll be no bother as all I'd have to do is boot it (remotely if I want), then launch the build script. Almost at that now. If that script (like builder on the other thing) can live in-tree, then others can roll their own variants by running a single script, or someone else can take over if I get shot down by pirates. Using my 'Mac' as a runner is probably not an option for a number of reasons.
Ok, your build results will be welcome.
I'm not sure what privileges you need to add artifacts to releases but am sure someone from the OoliteProject administration can grant the access.
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 279
Joined: Sun Feb 18, 2024 12:13 pm

Re: OoliteStarter

Post by MrFlibble »

hiran wrote: Wed Jun 12, 2024 2:39 pm
MrFlibble wrote: Tue Jun 11, 2024 8:42 pm
If I can boil the build process down to a script, it'll be no bother as all I'd have to do is boot it (remotely if I want), then launch the build script. Almost at that now. If that script (like builder on the other thing) can live in-tree, then others can roll their own variants by running a single script, or someone else can take over if I get shot down by pirates. Using my 'Mac' as a runner is probably not an option for a number of reasons.
Ok, your build results will be welcome.
I'm not sure what privileges you need to add artifacts to releases but am sure someone from the OoliteProject administration can grant the access.
Files can be added to a release by editing the release. Below the text and files will appear "Attach binaries by dropping them here or selecting them. " so, for now, if there's a particular version you want e.g. Cholly to try out just let me know. I'll roll it on-demand to a temp file host and post the link here. Doing so will lead me rapidly towards automation of the task. Old versions in x86_64 form can get lost once a better method is sorted, and/or development calms down.

Is there a 'current stable' of choice for me to do?
User avatar
hiran
Theorethicist
Posts: 2266
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: OoliteStarter

Post by hiran »

MrFlibble wrote: Wed Jun 12, 2024 2:45 pm
Is there a 'current stable' of choice for me to do?
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'.
Sunshine - Moonlight - Good Times - Oolite
User avatar
MrFlibble
---- E L I T E ----
---- E L I T E ----
Posts: 279
Joined: Sun Feb 18, 2024 12:13 pm

Re: OoliteStarter

Post by MrFlibble »

hiran wrote: Wed Jun 12, 2024 6:43 pm
MrFlibble wrote: Wed Jun 12, 2024 2:45 pm
Is there a 'current stable' of choice for me to do?
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)

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

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.
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
User avatar
hiran
Theorethicist
Posts: 2266
Joined: Fri Mar 26, 2021 1:39 pm
Location: a parallel world I created for myself. Some call it a singularity...

Re: OoliteStarter

Post by hiran »

MrFlibble wrote: Wed Jun 12, 2024 9:33 pm
hiran wrote: Wed Jun 12, 2024 6:43 pm
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.
MrFlibble wrote: Wed Jun 12, 2024 9:33 pm
These uploads will self-destruct on July 12th at about 22:22.
Ummmm - I hope I understand the scope right... ;-)
MrFlibble wrote: Wed Jun 12, 2024 9:33 pm
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.
MrFlibble wrote: Wed Jun 12, 2024 9:33 pm
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.
Sunshine - Moonlight - Good Times - Oolite
Post Reply