11 May
2017
11 May
'17
7:46 p.m.
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/