On 05/11/2017 07:19 AM, Vincent Massol wrote:

Hi,

The idea would be to do the same as what Jenkins is doing and provide an executable XWiki WAR using winstone: https://github.com/jenkinsci/winstone (it’s using Jetty).

This is the install doc of Jenkins: https://jenkins.io/doc/: " • Download Jenkins. • Open up a terminal in the download directory and run "java -jar jenkins.war" • Browse to http://localhost:8080 and follow the instructions to complete the installation. “

Actually what could be nice is that we could release a single WAR packaging for XWiki and: * Users could execute it as an executable WAR with java -jar xwiki.war (it would run Jetty) * Users could deploy it in their servlet container (in this case the embedded Jetty wouldn’t be used)

This would allow to release a single packaging and simplify things. It would also work on all OSes and don’t even need users to unzip anything!

WDYT?

For a regular computer user, running "java -jar xwiki.war" sounds even more complicated than double-clicking a .zip file, then double-clicking a .bat file (or just double-clicking a .jar file). Most Windows and MacOS people don't even know about the command line. So, I would say that having just a war isn't easier, but harder for users to start up on a desktop. On a Linux server, there are system-provided servlet container packages, which usually come with other nice things such as: - the ability to start automatically after a reboot, as a daemon - update more easily, especially after a security issue is fixed - configurations for logrotate, firewall, selinux... So, for a server the best package is a native one, (.rpm, .deb, or other formats), available in a repository. Or, the trend now is to have containers. A different question: is it a good idea to have a quick-try standalone package? I don't know how XWiki users treat the standalone package, but from my experience with PhenoTips, often users start with the standalone package on their computer, and then try to use it as a server application, and get in trouble when trying to: - share access with others - upgrade to a new version - transfer data between instances - move real data to a server An alternative is to only offer server-ready packages, and have online cloud demos for trying out the product. In this case, the standalone package may only be useful for devs, but for that scenario we could provide a mvn target that starts up Jetty. Anyway, back to this proposal: - I don't think it makes it easier to try out XWiki on a desktop, on the contrary - It may make it easier for an inexperienced sysadmin to quickly install and start XWiki on a server - But it also makes it harder to maintain the app long term - It bulks up the .war, but size is no longer a concern nowadays A single executable .war works for Jetty, Nexus, or other such apps because they're clearly server tools, only useful on a network, where most of the "clients" are other programs, and data comes from other machines. That's not true for XWiki, where a single user can start it on his desktop and play with it. So, a -0 to replace the .zip package, and a reluctant +0 to make the .war executable. -- Sergiu Dumitriu http://purl.org/net/sergiu/