For schools and universities, an installer should be created that installs Jalview not at the user level (%LocalAppData%), but at the machine level such as %ProgramData% or %ProgramFiles%.
The also requires the extension of the PATH system environment variable instead of the PATH user environment variable.
Perhaps installer parameters already exist to allow this. In any case, I could not find any hints or a prepared response file (.varfile) that realizes an “All Users” installation.
Hi Lenz! Many thanks for posting.
I’ve created an issue for this on your behalf at https://issues.jalview.org/browse/JAL-4057
I think this can be done by specifying the -d argument when running the installer in unattended mode from the command line (-q does this : install4j Help - Installer modes ).
This may already be done. I’ll check.
We could certainly provide some documentation to help others out with this. Right now, it is possible to generate your own response file by first performing an installation interactively, and then grabbing the responsefile from the installation directory (link to install4j docs) … did you try that ?
PS. I moved this topic out of the ‘Jalview in Schools’ category, which is primarly for discussion about the ‘Jalview in Schools’ activities.
I started the installer with the -h parameter which shows the typical parameters:
After that I installed Jalview with the default settings and picked up the response file “response.varfile” from the subfolder “.install4j” in the installation folder.
The response file must have the same name as the installer so that it is interpreted without the -varfile parameter. However, to be on the safe side, I have included the -varfile parameter. My response file looks like this:
install4j response file for Jalview 2.11.2.0
appendToPathAction$Boolean=true
createDesktopLinkAction$Boolean=false
sys.adminRights$Boolean=true
sys.component.1031$Boolean=true
sys.fileAssociation.extensions$StringArray=“jvp”,“jvl”,“amsa”,“annotations,jvannotations”,“biojson”,“blc”,“aln”,“txt”,“fa,fasta”,“features,jvfeatures”,“gb,gbk”,“gff2”,“gff3”,“concise,jnet”,“msf”,“pfam”,“phy”,“pileup”,“pir”,“rnaml”,“mat”,“stk,sto”
sys.fileAssociation.launchers$StringArray=“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”,“JALVIEW”
sys.installationDir=C:\ProgramData\Jalview
sys.languageId=en
My definitive command line looks like this:
Jalview-2_11_2_0-windows-x64-java_8.exe -q -splash -overwrite -varfile Jalview-2_11_2_0-windows-x64-java_8.varfile
Unfortunately, the result looks like this:
In the same way the desktop shortcut Jalview.lnk is created in %Userprofile%\Desktop (=single user) instead of %Public%\Desktop
In short, I recommend an installer that is suitable for Windows machines that multiple changing users log on to.
I must add that Jalview does not seem to be multi-user capable at all. No matter if I install it in %ProgramData% or %ProgramFiles%, when I log in with another user account and start Jalview without administrator privileges it hangs at 0%:
Hi Lenz,
Thanks for your question and observations.
You’re correct that Jalview’s current (installer) installation is not multi-user friendly, which is why the default location is in user-space rather than system space.
This is down to the launcher that Jalview uses, which has an automatic updating feature which requires write-permission in the installation. The automatic updates are very important as some of the third party services that Jalview uses can change (or break) with very little (or no) notice! Oddly this year in particular has seen quite a lot of that kind of thing!
It’s good to have a use-case where this is not the most appropriate kind of installation as we can boost the priority of work to allow system-wide installations (which either ignore updates – not our preferred solution, or download and check for updates in user-space, if the user doesn’t have admin status).
There are other ways to run Jalview that could be set up system wide (the executable JAR being one) but these lack some of the niceties of the installer (such as file associations).
Sorry this probably isn’t the answer you want just now, but hopefully we will be able to incorporate your ideas into future installers.
Ben
Thanks for clarification Ben.
I suspect there must be a way to split the installation, so each user has a localApp Jalview directory created on first launch which is writeable. Perhaps install4j has functions for this ?
However, many established applications follow a similar pattern to Jalview, e.g. Eclipse.
Jim.
