Using OJB Xdoclet in Eclipse

First of all, I copied the example Ant build file on the ojb xdoclet online reference (also available with the source distribution). Several attempts at running the build failed since ant produced an error to the effect that ojbdoclet was not a recognized sub-element of taskdef.

I therefore decided to comment out the outer taskdef element and left objdoclet as the a sub element of target. In Window > Preferences > Ant > Runtime > classpath, I added the xdoclet-ojb-module jar under Global Entries. I then clicked on the Tasks tab, and clicked on add new. In the resulting dialog, I gave the name of the task as ojbdoclet, selected the jar I had just added then selected the class file implementing the ant task - OjbDocletTask.


I then brought up the run dialog by clicking on the build file and selecting Run as > Ant build ... on the context menu. In the classpath tab, I added all the jars in the ojb binary distribution lib folder using the button add labelled external jars to the user entries section.

The build file, which also shows a task to delete the schema file during a build, is shown below:

<?xml version="1.0" encoding="UTF-8"?>

<project name="martinlaw-build" default="ojb-xdoclet">
<property name="destdir" value="./repository"/>
<property name="schemaFile" value="schema/schema.xml"/>

<target name="ojb-xdoclet" depends="delete-old-schema">
<!--
<taskdef name="ojbdoclet"
classname="xdoclet.modules.ojb.OjbDocletTask"
> --><!-- classpathref="build-classpath" -->
<!-- defined in eclipse ant > global entries > add jar > define task, add supporting jars to
build classpath under external tools configuration -->
<ojbdoclet destdir="${destdir}">
<fileset dir="../../main/java/edu/su/cv/ojb">
<!-- restrict to files with xdoclet markup only -->
<filename name="CourseTraining.java"/>
</fileset>
<ojbrepository destinationFile="repository_user.xml"/>
<torqueschema databaseName="placement_bundled" destinationFile="${schemaFile}" dtdUrl="database.dtd"/>
</ojbdoclet>
<!-- </taskdef> -->
</target>

<target name="delete-old-schema">
<delete>
<fileset dir="${destdir}">
<filename name="${schemaFile}" />
</fileset>
</delete>
</target>

</project>

Using yum behind a proxy

I was recently attempting to install a software on centos 5 and ran into an error with the yum install command as shown below:

Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=5&arch=x86_64&repo=os error was [Errno 4] IOError: <urlopen error (111, 'Connection refused')>

Setting the http_proxy did not help matters. I found documentation on forums that suggested adding the line proxy_http=http://proxy:port in /etc/yum.conf. That still did not help. I finally came across a post on centos forums that suggested that the setting to be made in /etc/yum.conf is actually proxy=... and not http_proxy=...

Image Locations for Pentaho Reports 3.0

My experience with pentaho's report designer is that at design time, images used in the report can be at any arbitrary location. On publishing them to the XML format, each image used in the report design (.report file) is placed in the same directory as the output file but with a new name in the format - Report_staticImage[N].[ext]. N is a number from zero depending on the number of images while ext is the original file extension e.g png.

This behaviour is bound to cause trouble for someone using different locations for the development and production environment. Ideally, the production environment should be setup to reflect the local or vice versa but sometimes this is not possible. To get round this, the production path should be created on the development environment and the desired solution folder linked to the repository location.

For example, let the production path be /path/to/prod/pentaho-solutions/solution1. In this case, the solution1 is the directory containing .xaction files and report templates (.xml). Let the development path be /path/to/dev/pentaho-solutions. A link should be created from the duplicated/replicated production path to the actual repository location on the development environment.

This means that the report designer and pentaho design studio on development will manipulate the files in /path/to/prod/pentaho-solutions/solution1, resulting in paths that will match the production environment on deployment. The local pentaho server, which in my case knows the repository location as /path/to/dev/pentaho-solutions, can access the solution directory as a link - /path/to/dev/pentaho-solutions/soft-link-to-solution1.

Katiba-Info Issues

Please report your issue (bug, error, feature request) as a comment on this blog post and I will endevour to create a separate blog post where a more detailed discussion can be held and updates posted. You may want to browse through the list of issues first before adding a comment. Thank you for the feedback.

Katiba-Info Issue: Text Wrapping

Text wrapping is not handled gracefully when the chat/email window is narrow. The solution for now is to resize the chat window so that the embedded line breaks can be moved to the end of the line. I am working on a removing the embedded line breaks and white space and the direction I am leaning to is using a regular expression. Suggestions are welcome.

Narrow chat window

Wide chat window

Katiba-Info Issue: Unicode characters

Email and chat output is unable to display unicode characters as shown below. I am reading an XML file into a cacheable byte array and thereafter wrapping that array in a ByteArrayInputStream which is in turn wrapped in a InputStreamReader with UTF-8 encoding for use in the XSLT transformation. Suggestions are welcome.

Kenya Constitution Lookup via Email, Chat

After several weeks of coding and hacking, I hosted katiba info on google app engine on Sept 1st. The applications is envisioned as a mobile friendly site that will allow articles and clauses in the Kenya constitution via email and chat.

Sept 1st was long after my self imposed deadline to have it online before the promulgation ceremony. The idea had started as a desire to have the constitution online in a way that people could access in a simple way. Katiba.mobi was already online but I wanted to utilize the app engine platform for its scaling capabilities. On an earlier project (Kura Info), I had used python and django and had been impressed by that combination which greatly simplified web application development.

Having decided that the user interface part will be a walkover, I turned to the data where I converted the PDF file to text using pdftotext. The task that faced me then was how to delimit the various sections of the document - chapters, articles, clauses, parts and so on. The articles are numbering is not restarted at the chapter level for the body of the document, so I extracted that portion for further analysis, leaving out the TOC and appendices. The complexity of breaking down the text file was dawning on me so I turned to a compiler construction book for ideas on how to automate the process of building parsers. The book led me to use flex for my first stage where chapter headings, article headings, article numbers and clauses were sorrounded by XML tags.

The next step according to compiler theory would have been to create a grammer, tokenize the file and feed it into bison. At that point, I decided to take a short cut by using regular expressions in python to finish the task of surrounding chapters, part and article sections with new XML tags. With an XML version of the constitution available, my original plan had been to use it to create another XML file in a format suitable for uploading to the datastore. This approach was abandoned due to the additional complexity and time pressure. I decided to use XPATH to mine the desired information. I quickly found out that XPATH support on google app engine (python) was only available as a third party library and decided to switch to Java due to its XML processing facilities.

I did not expect a repeat of the ease I had experienced while using django for the user interface so I went for a user interaction medium that demanded the least in terms of UI development - email. When email started was ready and the application hosted, adding chat was a straightforward process.