heh

well, those are mostly native or electron apps. but maybe that was your point 🙂

i'm collecting app ideas in github under the apps label

this month has been very busy so i've not had much time for graviton. next couple of weeks also look quite packed.

hopefully i'll be able to return to it soon

graviton browser looks cool, i would like to switch to that instead of my selfbuild janky sselfupdater from jenkins but is there any way that i can bundle graviton within a jar and pass arguents through so that users will not have to change their habits or scripts? eg just use

java -jar program.jar arguments...

and why did you decide to use

~/.m2/dev-local

instead of the usual

~/.m2/repository

aka

mavenLocal()

?

i think this could be simplifying things for my commandline apps and be a cool platform for a boardgame i am currently writing to explore mpp

i guess mavenLocal could e confusing for people who do still use maven and not just gradle for stuff

anther thing i did not quite understand in the docs: Online Update Non-goals:

Linux support - Linux users have their own platform level update mechanisms that can be reused.

does that mean jvm and graviiton do not selfupdate but apps do? or does this mean graviton does not work on linux ?

Graviton for Linux works fine and shipped along with a JVM. But since I've installed it by downloading and unpacking archive, `apt`/`apt-get`/`aptitude` knows nothing about it and won't apply any updates.

@Nikky hey there. there isn't any such a way at the moment, no.

@Nikky the idea is to get people to change their habits indeed, such that everyone benefits. also

java -jar foo.jar

isn't so easy to make work with maven, as the classpath involves jars from all over the place. it doesn't generate fat jars

~/.m2/dev-local

is because maven differentiates between caches and repositories.

dev-local

is a repository.

repository

is a cache (i know, it's confusing). the directories can't be merged, oddly enough.

@Nikky finally, I think that part of the docs is out of date. I did implement linux auto update in the end.

@miha-x64 yeah, indeed, apt doesn't update it and indeed cannot because apt likes to delete or modify files that are in use on disk, which will crash the JVM

so for now it's self-updating. a DEB usable with apt could be created, but it'd need some more coding work to ensure graviton shuts down if it's running, and then starts up again afterwards if it was shut down, etc.

its own mechanism is able to update itself whilst it's running

@Nikky if you can find a way to make graviton easier to use, please do let me know or even try writing a PR. i guess to make

java -jar foo.jar

work, graviton would have to manufacture fat JARs, but that's a bit tricky. it has a habit of breaking apps that aren't tested for it.

@Nikky what i want to do instead is this, maybe you will like it: have a directory in e.g.

~/.local/graviton/bin

where the background task puts executable shell scripts that relay to the main graviton execution command. you can then add this directory to your PATH and run programs as normal:

foo --bar

without even seeing that they're java

i even considered something slightly crazier, of allowing apps to advertise themselves with their preferred command line name, and then having popular apps automatically populate a separate directory, like

~/.local/graviton/appstore

- this can be added to the end of your PATH, and the background task would populate it automatically

so you can read about a new tool or app online, and then run it, and the command will be recognised already. it'll then pull down the dependencies and install all the JARs the first time it's used.

this is probably in the docs as well.. but can i somehow designate my program to use a specific java version by default? eg. declaring it in the manifest? that could then still be overridden by users

although that would only be useful if there is support for java 8-11 working

unfortunately there's currently no concept of manifest, nor different jvm versions. i've gone back and forth on whether to support that

the main issue is that the long-term vision is for it to be like a web browser

you can make a web app that refuses to work on anything but a specific version of a specific browser, but web app devs know that's not good practice

and it's not a built in part of the platform for that reason

Internet Explorer used to support web pages saying "i need to run in an old rendering engine" and the tab would be switched to old versions, but they dropped support for that after a while, and no other browser ever supported it. they just try to make things backwards compatible, and devs are expected to keep their app fresh

with java's new 6 month dev cycle i was thinking that's where java is going, so it'd make sense to just expect apps to keep up to date

Hello, I'm surprised there are still people in this old channel. But for those who are curious what happened to the Graviton Browser, the answer is that a few years later I founded a company with the goal of making app distribution much easier. Hydraulic Conveyor is a less radical approach than Graviton. It's a CLI tool that lets you easily package, sign/notarize, upload and update apps with one command. It builds for every target platform simultaneously, so you can release apps direct from your dev laptop regardless of what you use. There is no third party runtime or browser component; the JVM is bundled (and it also does Electron, Flutter and other stuff). It can also release directly to GitHub Releases/Pages. So this is if anything easier than Graviton was in some ways, as you don't need to release via Maven Central or convince users to install some third party program. The downside compared to the Graviton experiment is that you need to buy your own signing keys to get the best UX. Also, for commercial apps, you have to pay for it (it's free for open source apps). Conveyor made sense to build because although Graviton kept your apps up to date, it didn't actually have a good way to keep itself up to date, and the same issue applies to other third party updaters for the JVM/Kotlin ecosystem. Conveyorized apps use OS native update mechanisms (MSIX/Sparkle/apt-get) so it doesn't have that problem. I'm still interested in ideas and research around new web-like-but-not browsers. Some years later I wrote a design doc for a non-web protocol that would deliver some of the same benefits, but have no plans to implement it. https://docs.google.com/document/d/1oDBw4fWyRNug3_f5mXWdlgDI4J5AbxVWKEeYr6hscT8/edit?usp=sharing I'll leave this channel now to clean up my channel list but hope that if you still need a deployment and update solution for your apps, then Conveyor can help. I sometimes answer questions about it in #compose-desktop and #tornadofx, there's also a Discord where you can find us. Sayonara!