The .jar file distribution requires that users type a complex java command line to start the application.
Proposal: distribute a .zip file that contains the .jar as well as some wrapper scripts to start up the server.
Assumes either java 6 or java 7 is on the $PATH or %PATH%.
This is what you would get when you unpack the file:
archivesspace/
├── archivesspace.jar # jar file version of archivesspace
├── archivesspace.bat # windows batch file
├── archivesspace.sh # bash script for OS X and linux
├── config # directory to hold local config.rb
│ └── config.rb
├── data # keep application working data here
│ ├── derby
│ └── solr
├── log # log files from running java -jar redirected here
└── templates # ideally _template.erb.html could be overridden at run time
The wrapper script will supply all the java command line options, set up log files.
The script should work like an init.d script.
archivesspace.sh start
For windows, the .bat (or .cmd?) should work with RunAsService
http://stackoverflow.com/a/415453/1763984 run a batch file as a windows service
bash script for linux and OS X should use a cross platform technique to fork and detach from the tty.
nohup ./myscript 0<&- &> my.admin.log.file &
http://stackoverflow.com/a/10908325/1763984
# double background your script to have it detach from the tty
# cf. http://www.linux-mag.com/id/5981
(./program.sh &) &
http://stackoverflow.com/a/3430969/1763984
unzipping a new version on top of an old version will just update binary files, leaving data and configuration intact.
Something like:
./build/run dist:zip
should create the .zip distribution from the checked out source.
I really like this idea. The only slight unknown will be getting the templates under 'templates/' to override what's in the .jar, but I'm sure there's a way to do it.
Another nice side effect of distributing as a .zip is that we can split the gem dependencies out of archivesspace.jar and slim down the whole binary package. Currently it sits at around 100MB but that's mainly because of the gymnastics I had to pull to ship the whole lot as a single .jar file--it could definitely be much smaller. We could even pull the individual .war files out of the archivesspace.jar to make it easier for people to find them and deploy under other servlet containers if need be.