Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.



Release Process

The following are the steps to take when releasing a new version of JAMWiki:

  1. Prepare the release:
    1. mvn release:prepare -DautoVersionSubmodules=true -DdevelopmentVersion=1.3.3-SNAPSHOT -DreleaseVersion=1.3.2 -Dtag=1.3.2 -DpushChanges=false -DdryRun=true
    2. mvn release:clean
    3. mvn release:prepare -DautoVersionSubmodules=true -DdevelopmentVersion=1.3.3-SNAPSHOT -DreleaseVersion=1.3.2 -Dtag=1.3.2 -DpushChanges=false
    4. The war file is /branches/1.3.x/jamwiki-war/target/jamwiki-1.3.2.war.
    5. mvn release:clean
  2. Generate source archives:
    1. git checkout 1.3.2
    2. mvn install
    3. mvn assembly:assembly
    4. mvn clean
  3. Push Git changes
    1. git push origin 1.3.2
    2. git push origin 1.3.x
  4. Create the release notes for
  5. Upload the release WAR and source ZIP files to Sourceforge.
  6. Create the new Sourceforge release.
  7. Create a Sourceforge news announcement for the new release. Comments from Sourceforge:
    • Put the project name in the subject. That is, instead of saying "Version 2.3 released", say "FlightICS releases version 2.3". This makes it easier for news outlets to republish your news item.
    • Put a one sentence project description in the body. (Yes, every time.) This saves a news outlet time looking up what your project is, and increases the chance that they’ll pick up the story.
    • Put the URL of your news page in the body. This may seem redundant, but ensures that when the story appears somewhere else, they can still get back to your site. Provide a one-paragraph summary that is 140 characters or less. Being able to post your story on Twitter with no additional effort increases the chance that your story will spread.
  8. Update the StartingPoints and JAMWiki Release Archive pages.
  9. Send a release announcement to the mailing list.
  10. Add a new release announcement to
  11. Add a new release announcement to

Branch Process

  1. mvn release:branch -DautoVersionSubmodules=true -DdevelopmentVersion=2.0-SNAPSHOT -DreleaseVersion=1.3-SNAPSHOT -DbranchName=1.3.x -DdryRun=true
  2. mvn release:clean
  3. mvn release:branch -DautoVersionSubmodules=true -DdevelopmentVersion=2.0-SNAPSHOT -DreleaseVersion=1.3-SNAPSHOT -DbranchName=1.3.x


This list just captures stuff that I'm thinking about but that isn't fully fleshed out yet. Please note that anyone who wants to work on these items is welcome to do so, but as always please leave a note indicating what you're working on so that we don't duplicate effort.

  • Build some performance metrics (preferably automated) so that regressions and improvements can be tracked.
  • Plugins. It should be possible to implement hooks throughout the code (similar to Mediawiki) and then allow plugin authors to create a JAR that can be included in a JAMWiki installation. Assuming all plugins implement a similar interface JAMWiki could then auto-discover the plugin (or pick it up from a configuration file) and then copy any JSPs from the plugin JAR to the /WEB-INF/jsp/ folder to implement the plugin. Inititially I'd like to try moving some existing functionality (such as the spam filter) to use this sort of architecture before opening it up to widescale usage. Note also that plugins would need to implement some sort of "supported version" functionality as I don't want to have to freeze the plugin API forever.
  • WYSIWYG editor. See Tech:FCKEditor Integration, but note that an approach is needed that does not require Bliki.
  • User blocking as described on Roadmap#User blocking.
  • Front-end for spam filter, apply spam filter to edit comments and topic titles.
  • Talk pages for anonymous users as described on Roadmap#Anonymous user talk pages.
  • Display warning when uploading an image and an image of the same name already exists.
  • Provide a way to delete image files.
  • Alphabetical index for pagination as described in Feature Requests#Allpages pagination.
  • Pagination will link to a page with no elements when total % offset = 0.
  • Create a page to view and edit a user's current watchlist, as is done with Mediawiki. Please take a look @ this feedback.
  • "Link to" for redirects does not show final link destination. Update: this functionality isn't hard to add but has performance implications.
  • Allow wiki syntax in edit comments.
  • Question marks in topic titles - Sandbox
  • Look for ways to move some configuration files into PROP_BASE_FILE_DIR including to make upgrades less problematic since no files in /WEB-INF/classes would be overwritten.
  • Simplify the upgrade process, and potentially find a way to allow deployment as a normal WAR file (rather than an exploded WAR), which will require figuring out how to write property file and other updates to a permanent location.
  • - integrate his PD parser tests.
  • Feature Requests#Flash embed capability
  • See re: some JAMWiki performance testing.

JAMWiki description

I'm a better programmer than writer, and I find it frustrating to come up with decent descriptions of JAMWiki for sites like Freshmeat and such. Today, however, it looks like someone has done the job for me. From

Special Mention. It is not my habit to mention every new Wiki on my blog, but this time an exception seems necessary. JAMWiki has a few features that make it a bit different than other Wikis:

  • JAMWiki is a pure Java-based web application - that's a good feature for those of us already using a Java application server for other applications.
  • JAMWiki is quite flexible in its storage architecture: by adhering to standard SQL it seems capable to store the content in any more or less standard RDBMS, be it open source or commercial.
  • JAMWiki can even use the filing system to store the Wiki pages - handy for small installations or when you are just trying out the application.
  • JAMWiki has a pluggable Wiki syntax parser mechanism, making it possible to substitute your own preferred parser for the standard Mediawiki syntax parser - that's a great feature if your users have already been weened on another Wiki variant.

JAMWiki tries to be at least as good (and as feature-complete) as MediaWiki; it even recaptures the Wikipedia-look. That may not be the best way to try and gain a foothold on an already crowded market, but in an open-source context the classic rules of economic competition do not necessarily apply in the same way. And the more technical feature metioned may well be enough to make this a name to remember. Now I just want to know where JAMWiki got its name - in Dutch, "jam" means "marmelade"...

And to answer his question, the story of the JAMWiki name begins here.

Eclipse Notes

  • Need servlet.jar (version 2.4) - look in Maven repository (...\.m2\repository\javax\servlet\servlet-api\2.4\).
  • Need to run javadiff/mvn install and jamwiki/mvn package prior to creating the Eclipse project.
  • Need junit.jar in build path - look in Maven repository (...\.m2\repository\junit\junit\3.8.2\).
  • Need jsp-api.jar in build path - look in Maven repository (...\.m2\repository\javax\servlet\jsp-api\2.0\)