Using graalvm might interrupt plans for loading extensions for clj (particularly as it pertains to alternative types of package)
@dominicm could you elaborate? the graalvm part would only be a replacement for the bash/powerscript part (so you don't have to maintain bash/powerscript/whatever, but you can just write clojure), not for the jvm part
Ah, I assumed the intention would be to replace the whole ensemble.
Up to the launching of the user's jvm that is
are there multiple jvms involved when starting a tools.deps-classpath driven project?
one to compute classpath (if not cached?), one to launch, iiuc
ok, that would remain the same then
i think if one searched for JAVA_CMD in the bash script, details can be examined
the jvm already runs fine on all platforms, it's just the scripting parts that are messy (to maintain for multiple OSes and to install / set on the path in Windows, etc)
the multiple implementations (powershell, nim, go, rust, node) seem to be evidence in favor of that, iiuc
btw, with the latest ps download, Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
isn't enough here for a successful installation
i get something like:
.\win-install-1.10.1.489.ps1 : File C:\Users\user\Downloads\win-install-1.10.1.489.ps1 cannot be loaded. The file
C:\Users\user\Downloads\win-install-1.10.1.489.ps1 is not digitally signed. You cannot run this script on the current
system. For more information about running scripts and setting execution policy, see about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
the work-around suggested on the wiki does work, but it seems to me that the original suggestion isn't ever going to work if the script isn't signed -- does that seem right?
it might be nice if the zip file wasn't automatically fetched every time -- if there is one there already that's appropriate, for example