Table of Contents


Or, "Why do you use JSPWiki?"

Rough notes – work in progress only.

See also the feature summary on the front page at

Comments below are excerpts from mailing list discussions.

"Re. not enough extensions, maybe we don't have a plethora of extensions, but I find very easy to extend JSPWiki, that's one of its strengths and how I became interested in the project in the first place (like ages now)."

"Re. JSPWiki target, I don't expect a high technical user, even for the one(s) administering it. I only expect them to be able to reach from the downloads page to the getting started one.. Another question is if a non technical user prefers a wiki or ms word for his documents. And with 2.10.2 there will be portable binaries, so maybe there will be a reason less to not use JSPWiki.

As for companies using JSPWiki, I've seen mostly small/medium companies, but if I recall correctly, NetBeans did/does use JSPWiki, f.ex. "

"I really like JSPWiki's strengths (ease of setup, mostly ease of use, streamlined and no bloat, no separate database to manage, open source, and so on)"

"There are SME departments (or single guys) that might be interested in the features of JSPWiki. Your comments regarding configuration are valid though, it's a lot harder than need be.

The SME market could be one of those targeted with future (re)development."

In response to the statement "I am very curious as to why people would even want to install a wiki on their own machines (Windows or otherwise)":

You get a note-taking tool with text formatting, file attachments, hyperlinks between notes, a full-text search engine, and no dependency on network connectivity. You also get to keep past revisions, and can easily backup the data (or even read it if the software fails): it's just plain-text files.

I've used JSPWiki this way for a few years (and was using MoinMoin in a similar way before). Network connectivity was a major factor in choosing to use a local instance: data connections in high-speed trains were quite flaky, and clients often had restrictions on which web sites could be accessed. Not storing client data on a remote server was also seen as a bonus; the data is encrypted on my laptop. Network latency is also a bit irritating when you've gotten used to a local server.

The full-text search engine was not much of a criteria when I selected JSPWiki, but it turned out to be much more useful than I envisioned, especially on a local instance (no latency, very fast results).

By the way, I selected JSPWiki based on its syntax. I wanted to use a wiki that had a syntax close to what CollabNet TeamForge has, and it turns out JSPWiki is the only one that matches (to the point that I wonder if CollabNet forked JSPWiki a while ago).

See also this mailing thread that was kicked off in February 2016. Some excerpts:

  • "All Java, from web server to the application itself
  • No need for a separate database
  • File storage facilitates easy backup
  • Sufficient features for a simple website
  • Primarily text based so low bandwidth requirement
  • Small footprint"
  1. "I have used JSPWiki for 8 years as a developer's journal. Each day, I record everything I've done, stuff I've learned, tips tricks, etc.

  2. For the past three years, I've used it to store all my PhD research notes. The full text search with Lucene built-in is worth using it alone IMHO.

  3. In the last few months, I've installed JSPWiki to be used as the help system for my thesis project software. Rather than writing a ton of help files, I figured I'd just put up a few basic How To / Intro pages, and then provide a facility for users to write their own docs. JSPWiki is great for this.

If you're familiar with the Java J2EE stack, servlets, JSP, and Java web apps, then adding JSPWiki as a component is a natural thing".

"I like it cause it's lightweight. Easy to back up, and has a small memory footprint. And most importantly, it just works. It's also pure Java, which for me means that, as a Java developer, in future I can extend/enhance it."