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.

Tech comments:Maven



jflex - FIXED. Now available in Repository. See Mike

Note that all Maven mirrors are not in sync yet (for instance Sateh doesn't have de.jflex:jflex). However, in Europe, Skynet is up to date. Regis Decamps

The ant script used to generate the sources generated by JFlex in src/main/java I have changed this location to target/generated-sources.flex instead.

  • because it is the Maven convention to do so
  • because it seprates generated code from handwritten code (no more svn:ignore to manage)
  • because we don't want PMD/CPD warnings on a code that we can't change

-- Regis Decamps 23-Jul-2007 13:50 PDT

...jamwiki/jamwiki/src/main/java/org/jamwiki/parser/jflex/[234,2] cannot find symbol symbol : class JAMWikiPreProcessor location: class org.jamwiki.parser.jflex.JFlexParser Mike 23-Jul-2007 15:15 PDT

Just as a data point it seems like it's working OK for me using JDK 1.4 and the latest Subversion pom.xml file. -- Ryan 23-Jul-2007 21:14 PDT
Yes sorry, I have commited an incorrect version of the POM ( revision 1592 ). Hopefully, this was fixed in r1593. Also running mvn clean compile can help.
If you have this kind of NoClassDeFoundError in your IDE, don't forget to add target/generated-sources/jflex as a source folde. See the article for more details. Regis Decamps 24-Jul-2007 02:20 PDT
Still get this error. Jflex task isn't called. You have changed phase to 'generate', but it's not on the list on Mike 24-Jul-2007 03:28 PDT
The integration with Eclipse gave the impression it could work, but it can't. The maven-compiler-plugin looks in src/main/java only. The only way to do better is to write a maven-jlex-plugin... In the meantime r1601 is a rollback of r1590
Works again. Thanks. Mike 24-Jul-2007 10:38 PDT
OK, I have made a maven-flex-plugin, first commit is revision 1654 (hope you don't mind I use jamwiki svn for slightly OT things). I now need to get in touch with JFlex author to know what he wants to get this plugin in or if it should become an independent project (do you want it to remain in Jamwiki then?) Régis Décamps 28-Jul-2007 07:59 PDT
It seems fine to put this in the JAMWiki Subversion repository for now, but as you've said it should eventually either be made a part of JFlex, or if that's not possible it could be turned into an independent project. JFlex hasn't had a release in three years, so I'm not sure how active that project still is - I've spent some time looking at other lexers (see Tech comments:JAMWiki Design#Alternative parsers), but since the current parser works there hasn't been a big incentive to move to something other than JFlex yet. -- Ryan 28-Jul-2007 10:48 PDT


Moved from the Feedback page:

Hi Ryan, I recently discoverd a nice feature with maven 2 marking the developer-tag with the timezone (plus or minus) hours differnce from London-time ;-). So if someone adds an entry at 10 p.m. it may point out that he did it at 18 hours local time or even in the middle of the night. -- Michael Habbert 31-May-2007 11:00 PDT (local time is 20:12 ;-) )


What's the default encoding for source code files? It isn't utf-8. Mike

All of the Java files should use ANSI encoding I believe. Some of the language-specific files use UTF-8. If there's a reason why everything should use UTF-8 then the files could be updated. -- Ryan 14-Jul-2007 16:04 PDT
My plattform encoding is UTF-8 and therefore I would like to specify the encoding in the project definition. Eg. contains a Non-ASCII character and causes problems during compilation on my system. With ISO-8859-1 it works. Mike 14-Jul-2007 15:39 PDT
That file was created by a German user, so that might explain why the encoding is something other than ASCII. The committers for this project are spread around the world from the US to Europe to Japan, Ukraine, Mongolia, etc, so if we can keep the Java files in ASCII format it might work best as a lowest-common denominator encoding. If that's not possible then ISO-8859-1 or UTF-8 would be an acceptable alternative. -- Ryan 14-Jul-2007 16:04 PDT
Most IDE use the platform encoding, which can lead to many problems. Fortunately, Eclipse allow to redefine the encoding per project. I vote for all files in UTF-8 (I think it is the recommandation in the Java spec). Note that my platform is UTF-8, too. Regis Decamps
Specifying UTF-8 in the Maven scripts seems fine, especially since we've already got documentation and default topic files in double-byte languages such as Japanese. However, as much as possible I'd like to keep the Java source files ASCII-compatible since people tend to assume that source code files can be edited by most text editors. I realize that's kind of a pain for (for example) a Chinese programmer who wants to add an @author tag, but hopefully we can work around those issues as they come up. -- Ryan 22-Jul-2007 10:39 PDT


war-local is there as a convenience for developers, allowing frequent recompiles and redeployments using the same properties files and JDBC driver libraries. If Maven doesn't easily allow a way to deploy with local modifications then that task can probably be dropped, and developers will then have to come up with their own ways of making sure the right files are deployed when doing a local build. -- Ryan 13-Jul-2007 21:49 PDT
warlocal unpacks the war file, replaces properties und libs from a local-files directory and packs the war file again. It just for easy redeployment. Meanwhile I think, that an extra Maven plugin is an overkill for such a simple task. I have created a modified Ant task in mavenize.xml, which does the same, but you need Ant installed. I would like to run it from Maven. However it's not easy to run an Ant task from Maven that is not within an lifecycle. The Antrun plugin needs a phase where to attach its tasks. How knows more? Mike 15-Jul-2007 07:41 PDT

Thanks for your explainations. Follows what I suggest. Regis Decamps 22-Jul-2007 10:29 PDT At first, I thought war-local was designed to use a specific configuration for the developers. As such, I thought it would make sense to use

  • have templates for the configuration files
  • use profiles, the profile "default" being for the general public, the profile "dev" being for developers

But it is not the exactly what we need, I think. As I understand the requirement now, there is a need to save and JDBC drivers. Unfortunately, we don't have a file, it is produced by Special:Install

That leads no choice but to use the want task, called by maven.

Well, there is an alternative actually. The best practice in JavaEE is to place the configuration of the environment in the application server. This works for simple servlet containers too. In Tomcat, tomcat/shared is shared by webapps. As such, you can

  • copy your custom to tomcat/shared/classes/org.jamwiki/
  • copy your optional JDBC drivers and other librairies to tomcat/shared/lib/org.jamwiki/

This approach has several advantages:

  • there is no need to change the war once it is produced
  • the WAR is environment-independant

There are disadvantages, though:

  • people need to be aware of this (hope this helps)
  • the is shared by webapps. It means you can't have different versions of Jamwiki running on the same app server. (workaround: call the file
  • the is shared by webapps. It means any other webapp on the same server can access the configuration, which raises a security risk.
The war-local target was mostly just a convenience for me, so it's not a big deal if the Maven script doesn't offer that functionality. I usually have at least two versions of JAMWiki running on my laptop (a stable one that I use for notes, and the latest development code) so using the shared folder may not work, but it's easy enough to just write a shell script that deploys things as needed when I'm testing. For those who just want to share JDBC drivers and such your solution should work nicely, however - thanks for writing it up and investigating the local build issue in Maven. -- Ryan 22-Jul-2007 10:39 PDT


Should bliki be a sub project? I don't know the current status where it is maintained.

We can create a sub project. A better solution would be that User:axelclk publishes Bliki somewhere to a maven repository and we include this repository.

I don't know if in the Maven world it's better to have a "plugins" sub-project that contains bliki, or whether bliki should be its own sub-project. User:axelclk is the maintainer of bliki and I believe he maintains the code elsewhere. Ryan
Maven handles library dependencies itself as described in the POM.xml. Mentioning it in the POM is enough if the library exists in Otherwise if the library is not in (like bliki.jar) we can either install it your local repository with mvn install or let it leave in lib and define lib as a local repository (as commented at the end of the POM). Regis Decamps 15-Jul-2007 04:09 PDT
That's a good idea to create a repository for bliki. I will create an internal repository and install bliki there.Mike 15-Jul-2007 07:41 PDT

Status: OK. Bliki is provided with Jamwiki. Developers need to remember to update the jar the old fashioned-way.

Text files

Where is the final location in a war file for files like CREDITS.txt? Do we need them in the root directory in subversion?

CREDITS.txt (as well as LICENSE.txt, README.txt, CHANGELOG.txt and UPGRADE.txt) ends up in the root of the generated WAR file. These files do not need to be in the Subversion root if there is a reason why they should not be. Ryan
One can have have one's cake and eat it: Subversion handles Unix symlinks. The file can be in src/main/webapp (so that they are at the ROOT of the war) and there can be a symlink at the root of the Subversion repository (because I like to find the README easily when I browse a source repo). I do this, feel free to remove the symlinks. Regis Decamps 22-Jul-2007 10:41 PDT


Should we create a new project for JavaDiff or just keep source code in project? It's LGPL, too. So it's not a big deal to include it in our war file. Mike 15-Jul-2007 16:51 PDT
Mike has create a maven project called "org.jamwiki:javadiff". I follow this decision. Developers need to "cd jaavdiff ; mvn install" before being able to compile Jamwiki. Regis Decamps 22-Jul-2007 11:50 PDT
It's not necessary to install javadiff, you can go to /jamwiki-parent and call mvn package and it will package both sub projects. However without installing javadiff you cannot go to /jamwiki and execute Maven, because it wouldn't know javadiff. Mike 22-Jul-2007 18:00 PDT

Status: OK (distinct project)

IDE integration

See Building from Source

"mvn site" error

mvn site is giving me the following:

[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Error during page generation

Embedded error: Error rendering Maven report: Exit code: 1 - D:\code\workspace\w
iki\trunk\jamwiki\src\test\java\org\jamwiki\test\utils\ wa
rning: as of release 1.4, assert is a keyword, and may not be used as an identif
                        assert false;

I didn't really look into it, so I'm not sure if this is a JDK 1.4 issue or if something else is going on - hopefully this will be an obvious fix for someone else, if not I'll investigate later this week when I get a chance. -- Ryan 22-Jul-2007 21:10 PDT

I don't get the error on my system. However it's not recommended to use assertions in a test case. You can just use the JUnit method fail() and write fail("Some reason"). In test cases it is even better to declare the exception of this catch block and let JUnit catch it. I have changed to my suggested way. Mike 23-Jul-2007 05:35 PDT

Junit Test Suite

Thanks to Maven (and junit eclipse plugin), I think there is really no need for the TestSuite class any more. I sugguest deleting it.