Niggle comes with 2 prebuilt jars, niggle.jar and oreo.jar and, besides this, the <ROOT>/lib directory contains all of the third-party libraries that Niggle and Oreo use. So, you may have no need to rebuild from source. Nonetheless, there are a couple of basic reasons to do so. The first is if you want to change the behavior of the template variables to being case-sensitive. The other is that you want to expose your DataSources or DataRegistry objects as remote interfaces via RMI. And naturally, if you want to change anything else, you are free too, this being open source, but then you obviously have to be able to rebuild from the source.
Note that the out-of-the-box build script is an ant build file, build.xml. If you do not have the ant build tool, you can download it from the Jakarta site.
Since version 1.0 final, freemarker template variables are case-sensitive by default. This means that ${foo} or ${FOO} or ${Foo} are all distinct. This is also the way Freemarker and WebMacro work by default. (Though in the case of WebMacro, this would be $foo, $FOO or $Foo, of course.) In earlier versions of Niggle, the template variables were case-insensitive, this being based on the belief that this meshes better with HTML, which is also case-insensitive. Now, this is the very first version that also works with WebMacro, and WebMacro also has a case-sensitive syntax, so I decided that I was going against the flow.
However, if you want to change this behavior back to being case-insensitive, you can simply change one constant in the source code and rebuild. That constant is: CASE_INSENSITIVE in the file src/com/niggle/templates/freemarkerimpl/FreemarkerPresentationWrapper.java. This only applies to using Freemarker. WebMacro is always case-sensitive.
Once you change this, you can rebuild the jar with: ant compile
jars
The Oreo DataRegistry and the Oreo DataSource objects can be set up as remote RMI interfaces. This is actually a very powerful out-of-the-box capability they have. For example, it can be extremely useful if you want to have a remote administration interface to your application. Nonetheless, by default, the relevant base classes do not extend UnicastRemoteObject and nor does the niggle.jar contain the stub and skeleton classes needed by the RMI engine. The reason for this is actually rather technical. I discovered that in my own web-hosting ISP, that I could not deploy Niggle-based web apps there because they ran into SecurityManager restrictions. This was because of the RMI stuff. By turning it off, I was able to successfully deploy Niggle-based servlets there. A side issue is that, when you are not using RMI, it is annoying to have rmic as a step in your build process, since it is so slow, so there is already a strong reason to turn this on only if you are actually going to use RMI.
To rebuild Oreo with RMI capabilities you must:
ant compile rmic jars
Now, you should have the RMI capabilities built into Niggle.