This is the changelog of past releases
0.6.x
0.6.4
Released 09-March-2008 - Changelog
Non-embedded parser
It might be worthwhile to turn the parser into a standalone tool, which would have several advantages:
- It would force the interface to be cleaned up.
- It would allow others to use the parser as an independent tool, likely inviting additional development and spreading the stress of remaining mediawiki format compliant among many other tools that have a need to read/write this de facto standard format
- As of revision 2027 it is now possible to use the parser as a standalone application, although further cleanup of the interfaces will need to take place before this will be an easy-to-use implementation. -- Ryan 17-Feb-2008 22:25 PST
contrary position - keep mediawiki format absolutely central
A good reason NOT to do this is that the option to swap in another parser that obeys a format other than mediawiki's native format will be very tempting to a lot of users. Supporting such users will distract from the very difficult job of keeping up with mediawiki's native format so there are absolutely no pages written in mediawiki that aren't instantly portable back and forth to jamwiki.
Even the slightest failure in this regard is disastrous, it could cause entire populations using specific languages to stop using jamwiki (imagine if the way some character that occurs only in Hindi is treated differently in jamwiki and it causes a billion people to be unable to import readable Wikipedia pages into jamwiki without errors). Accordingly splitting development effort is unwise.
If people, especially sophisticated developers, begin to think of jamwiki's mediawiki format compliance as "optional" or a "parameter" they can change, the entire project can die dead right there. Or worse, lead to PHP and "real" mediawiki invading Java shops. Which is something we really don't want to see. ;-)
- For what it's worth, since the beginning JAMWiki has supported the ability to "swap out" parsers by changing an option in the JAMWiki configuration, and early in JAMWiki's development User:axelclk contributed the Bliki parser. Support for parsing Very Quick Wiki syntax was also available at one point, but it was dropped due to lack of interest.
- In general the capability to configure what parser is used has been seen as a positive feature since different individuals like different syntaxes, and supporting a variety of syntaxes provides a good way for individuals to transition existing wikis to JAMWiki without losing content. Additionally, should the default Mediawiki parser ever be rewritten, having the ability to easily change parsers makes it possible to support the new parser as an "experimental" version for several releases while bugs are worked out before removing the legacy parser. Support for Mediawiki syntax will remain the primary focus of development, but allowing interested users to drop in a parser for their favorite syntax is something that would hopefully draw developers into the project rather than fragment or kill the project. -- Ryan 17-Feb-2008 22:25 PST
0.6.3
Released 13-January-2008 - Changelog
0.6.2
Released 26-November-2007 - Changelog
0.6.1
Released 21-Ocotober-2007 - Changelog
0.6.0
Released 03-September-2007 - Changelog
Maven Support
Maven is an interesting project management framework. Discuss how this can be used for Jamwiki Tech:Maven
0.5.x
0.5.4
Released 06-May-2007 - Changelog
0.5.3
Released 03-April-2007 - Changelog
0.5.2
Released 02-March-2007 - Changelog
0.5.1
Released 28-January-2007 - Changelog
Spam filter
Assuming JAMWiki gains in popularity it will face the same automated spam attacks that Mediawiki faces. In such a case an automated spam filter will be required. Ideally this filter should contain an editable list of regular expressions that can be compared against prior to saving an edit. There should probably also be some sort of spam whitelist for corner cases.
A captcha utility is also required because spam filters are hard to configure and often problematic.
0.5.0
Released 03-January-2007 - Changelog
Parser caching
Look into something like ehcache or another of the existing caching solutions (see here) to cache parser output, which should significantly improve performance (as suggested by User:axelclk).
LDAP Support
Large companies and increasingly others commonly use LDAP or some other centralized directory server to store user account information. The old Very Query Wiki code contained LDAP support, but due to the fact that developers of JAMWiki do not currently have access to LDAP for testing purposes that support has been removed in JAMWiki. Once someone who has access to an LDAP server is interested in doing so the LDAP code should be restored and full LDAP support added.
Preferred Language
User should be able to specific their preferred language. Currently translations default to whatever language is specified by the browser. See also Tech:Preferred Language.
Automatic code validation
Look into http://pmd.sourceforge.net and other similar tools for automatically detecting programming errors.
XML Import/Export
XML import and export is useful for complying with open source licenses such as the GFDL and the CC-SA license, as it allows the full history of an article to be downloaded and credited. However, while this feature may be implemented in some form to allow for testing using data from other wikis, it will probably not be implemented as a fully supported feature for a while.
0.4.x
0.4.3
Released 09-November-2006 - Changelog
Translations for Default Topics
Currently StartingPoints, StyleSheet and BottomArea are set up by default, but are also English-only. JAMWiki 0.1.2 will include some underlying functionality for using country & language specific versions of these files, but full support will need to be added to a later version.
References
Support the Mediawiki references. See http://meta.wikimedia.org/wiki/Help:Footnotes for details.
0.4.2
Released 01-November-2006 - Changelog
Watchlist
A watchlist allows a user to keep track of a list of articles. This feature is useful on heavily trafficked Wikis where it can be difficult to see what articles of interest have recently changed. The watchlist can also optionally be tied in with email notifications to possibly provide a daily update of what has changed. See http://meta.wikimedia.org/wiki/Help:Watching_pages for further details.
0.4.1
Released 24-October-2006 - Changelog
- Fix a bug during setup that could incorrectly report a database conflict.
0.4.0
Released 21-October-2006 - Changelog
- DB2 & MS SQL support
- Mediawiki templates
- File persistency overhaul
File persistency
The current JAMWiki file persistency mode utilizes numerous XML files saved to the file system. As JAMWiki grows in complexity this file-management method is becoming overly complex. Shipping a default Java database with JAMWiki and using that for file persistency will significantly simplify the JAMWiki code, make testing and maintenance easier, and should also provide some performance benefit. HSQL DB is licensed under the BSD license and can be shipped with JAMWiki. The jar file is less than 500kb in size, and while large is still small enough to ship as part of the JAMWiki distribution. Using this database would provide individuals who do not want to install an external database a way of using JAMWiki, and would still meet the project's goal of not requiring an external database. Of course, users who want to use an external database will still be able to do so. -- Ryan 27-Sep-2006 16:04 PDT
Hi, plz take a look: http://www.h2database.com/html/images/performance.png
http://www.infoq.com/news/h2-released
jar is 900 kb -- AleXis 27-Sep-2006 20:16 PDT
- Thanks for the info - haven't seen you here in a while! According to http://www.h2database.com/html/frame.html?performance.html&main HSQL is faster for everything but updates and transactions (which JAMWiki doesn't use), but there may be other advantages to H2 that I'm unaware of - I'll keep reading, but if you're aware of anything please let me know. -- Ryan 27-Sep-2006 20:49 PDT
- Strictly speaking, JAMWiki does do updates (STATEMENT_UPDATE_TOPIC, STATEMENT_UPDATE_WIKI_FILE, etc), and it SHOULD be using transactions (when inserting topics/versions, multiple queries are used, should be contained in a single transaction). -- scroco 28-Sep-2006 18:48 PDT
- Actually I think I've gotten my terminology mixed up. JAMWiki does explicitly use commit() and rollback() when executing multiple statements, and has since version 0.1.0. It does not use CallableStatements, which is what I confused with transactions. Apologies for the mixup. And of course JAMWiki performs updates - I didn't write that as clearly as I should have. -- Ryan 28-Sep-2006 20:11 PDT
- Strictly speaking, JAMWiki does do updates (STATEMENT_UPDATE_TOPIC, STATEMENT_UPDATE_WIKI_FILE, etc), and it SHOULD be using transactions (when inserting topics/versions, multiple queries are used, should be contained in a single transaction). -- scroco 28-Sep-2006 18:48 PDT
Templates
MediaWiki templates are extremely useful ways to standardize code. They must eventually be implemented in JAMWiki, but they will require extensive testing and will probably not be implemented as a fully supported feature for some time yet. Most likely templates could be implemented as a configurable option first to allow some time for testing and for early-adopters, and only once any major bugs have been discovered would they be implemented by default.
0.3.x
0.3.6
Released 04-October-2006 - Changelog
- Fix a bug that caused setup to fail.
0.3.5
Released 29-September-2006 - Changelog
- Interwiki links (example: Wikipedia:Main Page).
- Pagination support.
- Preliminary DB/2 and MS SQL support.
0.3.4
Released 21-September-2006 - Changelog
- Add some validation checks and warnings for invalid admin screen data.
- Configurable signatures
Configurable Signatures
Make the inline signatures of style "~~" configurable per installation. Add two settings to jamwiki.properties, which would be available in the Environment, "sig-name-format" and "sig-date-format".
sig-date-format can be any valid date format.
sig-name-format can use wiki link syntax, and can include the below predefined variables (or can just be text, no link):
{0} - user ID
{1} - user login
{2} - user display name
{3} - user email
Examples:
sig-name-format=[[User:{1}|{1}]]
sig-date-format=dd-MMM-yyyy HH:mm zzz
sig-name-format=[[Special:User?user={0}|{2}]]
sig-date-format=dd-MMM-yyyy
sig-name-format={3}
sig-date-format=dd-MMM-yy
And rework ParserUtil.buildWikiSignature() to get the settings from the Environment and build the appropriate signatures.
- I've started on this one but have hit a snag. Currently if a user page doesn't yet exist then the parser creates a link to an edit page. Would you be OK with changing the above to the following:
- {0} - user page (either "User:wrh2" or "Special:Edit?topic=User:wrh2")
- {1} - user contributions page ("Special:Contributions?contributor=wrh2")
- {2} - user login
- {3} - user display name
- {4} - user email
- User ID shouldn't ever be needed so I've dropped that from the list. I'll go ahead with this shortly, but please let me know if it won't work for you. -- Ryan 14-Sep-2006 12:38 PDT
- I do need user ID. I've modified my installation to use a customized user model because I have an existing user base that I am integrating with. For me, user ID is essential. If you feel strongly that ID is not needed in a general sense, I can just modify my installation some more to make it work for me. No bigggie. Thanks. -- scroco 15-Sep-2006 10:10 PDT
- No problem it's easy enough to add and I'll get it in the next beta. Are the remaining options enough? I was thinking it would be nice to also have an option to link to the user comments page, which would change the list to the following:
- {0} - user page (either "User:wrh2" or "Special:Edit?topic=User:wrh2")
- {1} - user contributions page ("Special:Contributions?contributor=wrh2")
- {2} - user comments page ("User comments:wrh2" or "Special:Edit?topic=User_talk:wrh2")
- {3} - user login
- {4} - user display name
- {5} - user email
- {6} - user id
- -- Ryan 15-Sep-2006 10:14 PDT
- No problem it's easy enough to add and I'll get it in the next beta. Are the remaining options enough? I was thinking it would be nice to also have an option to link to the user comments page, which would change the list to the following:
- I do need user ID. I've modified my installation to use a customized user model because I have an existing user base that I am integrating with. For me, user ID is essential. If you feel strongly that ID is not needed in a general sense, I can just modify my installation some more to make it work for me. No bigggie. Thanks. -- scroco 15-Sep-2006 10:10 PDT
Yup, that sounds good to me. The more the merrier, you never know what some future install might need or want. -- scroco 15-Sep-2006 10:23 PDT
- Quick question - for anonymous users, what would you prefer for user id to be? My first thought is that -1 would be easiest, but I can return an empty string, 0 or some other value if that works better with your installation. -- Ryan 15-Sep-2006 10:38 PDT
- Honestly, it doesn't matter to me. In my system there's no such thing as an anonymous user. Anonymous users have no rights, can't edit, can't have a signature. That said, -1 seems like a reasonable value. -- scroco 15-Sep-2006 15:34 PDT
0.3.3
Released 01-September-2006 - Changelog
- Fix a bug that broke JAMWiki on the Resin web application server.
0.3.2
Released 29-August-2006 - Changelog
- Fix a bug that broke uploads while in file persistency mode.
0.3.1
Released 28-August-2006 - Changelog
- Page move / redirect
- Store history for translation files as Wiki topics.
- Address case-sensitivity issues with Wiki topic and user names - partially implemented.
Page Move/Redirect
Functionality for moving a page must be implemented. The MediaWiki #REDIRECT syntax, as well as a front-end page (such as Special:Move) that allows a page to be moved to a new location are useful functions, and the ability to automatically redirect a link from a moved page to the new location is also vital.
Translation File History
This feature has been partially implemented. Changes made using Special:Translation are now saved as Wiki topics, but manually updating the translation files will not cause a new topic version to be saved.
Translations are currently stored in ApplicationResources.properties files, and changes to these files are done either via manual updates or by using the Special:Translation tool. It would be nice if these files were also stored as Wiki topics, thus providing a way of saving file history. Using a property file that contained topic names and relative file names, and then checking this file during topic updates to see if a topic should be saved, would be an easy way to implement this feature. The only additional difficulty would then be making sure that the topic is upgraded after manual edits are made to the application resources file. Note that this mechanism could also be used for any additional files that were kept on the system and might need to be updated by users or system administrators.
0.3.0
Released 23-August-2006 - Changelog
- Special:Manage
- Mediawiki categories
Special:Manage
Replace the read-only section on Special:Admin and the Special:Delete tab with a single Special:Manage page that would appear as a tab on topic pages (for admins) and would provide the capability to make a topic read-only, admin-only, or to delete the page. This page would eventually also be the place where more specific permissions could be added for a page.
Categories
Mediawiki categories provide the capability for automatically organizing content, and providing index pages for that content. See http://meta.wikimedia.org/wiki/Help:Category for further details. Some notes:
- A new page, Special:Categories, should also be created to display a list of all categories.
- Images in categories should be displayed as a thumbnail index.
- Categories can be given a sort key to be used when sorting [[Category:category name|sort key]].
0.2.x
0.2.1
Released 16-August-2006 - Changelog
- Image resizing / thumbnail support.
Image resizing
Currently all uploaded images are displayed in the size in which they were uploaded. Automated image resizing should be implemented so that syntax of the form [[Image:Foo.jpg|300px]] can produce an image whose maximum width/height is 300px.
Full MediaWiki style image tag, supports sizing and alignment: [[Image:Foo.jpg|thumb|right|100px|Caption text]]
0.2.0
Released 12-August-2006 - Changelog
- Remove Special:OrphanedTopics functionality - broken.
- Remove Special:ToDoTopics functionality - broken.
- Search engine cleanups.
- Upgrade dependency jar files.
- Split up the spring.jar file and include only those sub-components that are needed.
- "What links here?" support.
- Other miscellaneous cleanups/fixes.
What links here?
Each topic should include the capability to see what links to it. The current search engine code might offer an easy way of providing this functionality, or some other method could be determined.
0.1.x
0.1.3
Released 05-August-2006 - Changelog
- Fix setup for databases that use the "ansi" setup option (broken since JAMWiki 0.1.1).
- Fix Resin issues (taglibs, character set for CSS, etc).
- Fix WebSphere property issues.
0.1.2
Released 04-August-2006 - Changelog
- Resolve issues with non-ASCII characters.
- Resolve scripting issues reported by NickJ.
- Resolve some parser failures (see Known Issues#Parser).
- Try to get rid of the Utilities.getMessage() methods & move to JSP.
- Other miscellaneous cleanups/fixes.
0.1.1
Released 31-July-2006 - Changelog
- Translation GUI
- Bugfix & cleanup release - 0.1.0 had a lot of changes, and I'd like to spend some time simplifying some parts of the code that have gotten a bit difficult to understand.
- Minor edit support.
- Move sql into properties files
Translation GUI
Translated message strings are kept in ApplicationResources.properties files. It should be fairly simple to provide a front end for someone to enter new or custom message strings and then save them to these files. An additional advantage is that if it's easier for people to create translation files then (hopefully) JAMWiki will be translated to support more languages.
0.1.0
Released 27-July-2006 - Changelog
- Section edits.
- Database transaction rollback - ensure that if something fails all work is rolled back to a clean state. May get bumped to a later release.
- Improved error handling - add checks to the admin tool to validate submitted values.
- Allow Wiki links to virtual wikis.
Section edits
Currently the only way to edit a page is to click the "Edit" tab at the top of the page, and then edit the entire page. For long pages this is unwieldy and prone to error. Adding "edit" links to each section is easier to deal with and less error-prone. It should be possible to implement this kind of functionality by including the start and end line numbers of the section being edited, and to then splice together partial content after an edit is made.
"Revert to" in History tab
Add button "Revert to version" on History and Version page for quickest version control. UPDATE: this has been implemented by allowing an older version of a page to be edited and saved, similar to what is described on http://en.wikipedia.org/wiki/Help:Reverting.
0.0.x
0.0.9
Released 24-July-2006 - Changelog
- Bugfix for infinite loop bug during setup.
0.0.8
Released 20-July-2006 - Changelog
- Fix JDK 1.4 file persistency bug.
- Support automated upgrades of database, etc.
- Stronger password encryption using a Hash algorithm.
Automated upgrades
For versions up to 0.0.7, any upgrade that included database changes required users to manually execute SQL to upgrade the database format. Instead, set a property file value with the last know JAMWiki version, and run a check to see if the code version matches the property file version. If not, trigger an upgrade script. This could potentially be messy to maintain, but it's worth giving it a try. Hopefully longer term things will stabilize enough that database schema changes are rare.
Hashing passwords
Store user password as HASH. Additional info: ForgottenPassword. Code implemented for this change will first see if the password in the database matches the SHA-512 hash. If not it tests against Base64 encoding. If the Base64 encoding matches the password is re-encoded SHA-512 and updated in the database. This could also be handled by an update script that converts all existing password to SHA-512, but I don't know if there are enough JAMWiki users out there to justify the effort.
0.0.7
Released 18-July-2006 - Changelog
- Separate stylesheet.
- Improved internationalization support (remove hard-coded message strings).
- Other cleanups including resolution of parser issues.
- Remove topic locking - may not make it into this release, in which case it will be bumped to 0.0.8.
International translations
Ongoing, this issue will be tracked through the Known Issues and Bug Reports pages from now on
All text messages on the system should be stored in ApplicationResources property values. Ideally an admin screen should be available to allow admins to customize the messages in these files without having to manually edit a properties file.
Remove topic locking
The current locking scheme is a remnant of the Very Quick Wiki code on which JAMWiki is based. Unfortunately this locking scheme is a bit klunky, and is not always useful. It should be possible to eliminate locking altogether, and simply add a check prior to saving to see if someone else has saved a version of the topic since the current user checked their version out. By simply including a field such as "lastTopicVersionId" with the current edit, and then verifying that no new version has been created, locking can be eliminated. In the case where a new version has been created, an interface will need to be created to show the editor the diff between the new version and his version, and to then reconcile the differences manually.
0.0.6
Released 14-July-2006 - Changelog
- Basic file handing:
- Minimal upload support for images.
- Minimal image display support.
File handling
While there is attachment code present in the current software it is entirely leftover from the Very Quick Wiki code and completely untested, despite a massive number of changes to the rest of the software. This code needs to be updated, and should behave more like MediaWiki. While image resizing and similar functionality probably will not be provided in the near future, simple handling of images and storing of file versions is an important feature.
0.0.5
Released 11-July-2006 - Changelog
- Improved database support:
- Make SQL code more generic.
- Test with MySQL and Oracle in addition to Postgres.
Multiple database support
Oracle and MySql support implemented for JAMWiki 0.0.5, released on 11-July-2006
One of the advantages of the Java language is that the JDBC framework makes it reasonably simple to support multiple databases. The most difficult issue to deal with is the fact that different database vendors use different SQL syntax, but this can be overcome by using standard ANSI SQL as much as possible, and by providing a way to implement database-specific SQL statements where needed.
0.0.4
Released 08-July-2006 - Changelog
- Improved user support:
- User pages and user comment pages.
- Ability to query user contributions.
- "Remember me" for login.
- MediaWiki signatures ("[[User:wrh2|Ryan]] 08-Jul-2006 18:09 PDT").
- Add error handling - no more stack traces should appear to end users.
User Accounts
Implemented for JAMWiki 0.0.4, released on 08-July-2006
There must be the capability to create a user account with a login and password. Having that ability allows accurate histories to be kept, provides the ability for a community to develop on the Wiki, and in general is just a good thing. Implementing user accounts is a high-priority, but it needs to be done in a way that is maintainable and compatible with LDAP systems for users who choose to use such a system. Note that integration with LDAP is not a "must-have" feature for a major release, but any user account system must be compatible with future LDAP support. Additionally, any login system must have the ability to set "Remember me" cookies to keep a user logged in across sessions.
Comments Pages
Mostly implemented for JAMWiki 0.0.4, released on 08-July-2006
The current "Comments" tab at the top of pages does allow a pseudo-comments page to be created, but it is buggy and there is no real connection between a page and its talk page. Anyone could potentially just create a new topic with a name like "Comments:New Topic" and the system would not recognize it as a "fake" talk page. Without talk pages it is impossible to discuss a work that is being developed collaboratively, so that functionality is a must-have before a major release can occur.