User:Wrh2

Ryan Holliday

IMPORTANT: Please do not email me directly with questions and support requests! Questions and support requests should be posted on the Feedback page so that anyone in the community can answer, and to give others a chance to benefit from that answer. Emails sent to me directly will first be attacked mercilessly by my spam filter, and should it get past that barrier it will likely waste away in my inbox, waiting for the never-to-come day when I actually catch up with responses to my backlog of mail.

There's more to be found about me here.

Release Process

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

Tag the new release in Subversion (example: tags/release-0.6.0).
Create the release notes for jamwiki.org.
Upload the release WAR and source ZIP files to Sourceforge.
Create the new Sourceforge release.
Create a Sourceforge news announcement for the new release.
Update the jamwiki.org StartingPoints and JAMWiki Release Archive pages.
Send a release announcement to the jamwiki-announce@lists.sourceforge.net mailing list.
Add a new release announcement to http://freshmeat.net/.
Add a new release announcement to http://wikimatrix.org/.

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 http://nukleos.editthispage.com/2006/11/12:

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.

Notes

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.

Modify the webtests folder to use Maven - having so many JAR files in the repository slows checkouts and increases repository size noticeably.
~~File history needs to show the user who uploaded the file.~~
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.
Parser: allow any attribute with an HTML tag, but strip out those that are invalid. Currently if an invalid attribute is specified the entire tag is escaped as invalid.
Front-end for spam filter, apply spam filter to edit comments and topic titles.
Clean up & better utilize caching.
Talk pages for anonymous users as described on Roadmap#Anonymous user talk pages.
Add support for the Mediawiki <gallery> tag.
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.
Add support for substitution such as {{subst:template}}.
Fix parameter substitution for named / unnamed per the spec.
Potentially add support for the msgnw option (does anyone use this?).
Template inclusion breaks section edit links (numbering off). Update: for now I've disabled section editing on pages that use template inclusion. This isn't a long-term solution, but thus far I haven't come up with a good way to handle this issue.
"Link to" for redirects does not show final link destination. Update: this functionality isn't hard to add but has performance implications.
Address case sensitivity issues for topic names and user names. Update: constraint added to the database to ensure user logins are unique in a case-insensitive way.
Translated category namespace may cause failure when adding/removing categories - see Bug Reports#Categories.
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.
http://nickj.org/MediaWiki - integrate his PD parser tests.
Feature Requests#Flash embed capability
See http://www.gossamer-threads.com/lists/wiki/mediawiki/139039 re: some JAMWiki performance testing.
Review Bug Reports/Archive for anything that might still be relevant.

Eclipse Notes