SQL to Java Code Generator Code

Made some changes to wrongfully declared tasks

Modified the build file to make use of hudson's properties. Also supplied two property files holding the settings for the build file.

If hudson won't be used for executing, the project.properties file will be read. If hudson will be used, the properties inside the project.properties file will be supplied by hudson

I have made some changes to the templates. We've starting the porting process ...

Added some basic support for holding database relationship information

Port of the Listener Template

Woops, forgot to commit the changes to the launcher. You'll need this if you want to use my configuration.

Ok, maybe it's best if I do submit the already (partially) ported templates. I'm using these to test the new version, looking for any flaws or shortcomings.

Maybe interesting to say, I'm using PostgreSQL 8.3 to do my testing. It would be great if someone would have a go with the current version on some other database.

Made some minor modifications while porting the 'java' templates:

- JavaDataType : Added a flag which indicates if the datatype can be compared using a compareTo method

- Table : Added methods to address the primary keys of the table

- Column : Added a fullname property which can be used to retrieve the 'table.column'
: Also modified the datatype property. It was holding an int-value while it should hold a SQLDataType.

- NodeParameterHandler : When a node is added to the handler, the node's parents will be added too. This comes in very handy while addressing nodes inside the templates as well as inside the package descriptor. Instead of using the current scope as the node to execute the method, the node type should be supplied.

- CamelCaseStringReference : Was added to convert underscored names (real_big_number) to camelcased ones (realBigNumber). This is not working atm.

Added a Velocity reference injection listener. This listener will make sure references are parsed using the StringParser and the current node before they are injected into the template.

I recreated strong-typed dataholders. They are needed because certain functionalities are specific to only one type of dataholder. For example relationships are only a concern of a table.

I also rearranged the dataholders. As they used to be located inside the commons.beans package, the are now moved to the data.holders package.

One major difference from the previous versions is the availability of nodes. Every dataholder is a node and as such, can be located inside the tree by using a path. We can use this later on to address specific nodes.