It’s coming to that time again. That time where I draw a line in the README file and call it a release. Being the only developer on a project that doesn’t have a large user base, a release is really just a state of mind. Like the flying ants that decide on mass to pour forth from their nests without the aid of any social media – it becomes time for a release.
The desire to release, to mark achievements and to demonstrate progress to the world is compelling but it is tempered by the chores a release involves – update the doc, double test everything, and resist the urge for that one last killer feature.
As I force myself down the home straight, I thought I’d share some of the cool new features in Oddjob 1.2, starting with…
Dynamic Form Generation for a Bean.
For several Oddjob versions now, if you provide an element mapping for a bean,
Oddjob will dynamically create a form for you based on the writeable properties of that bean.
Here’s one such example, it’s the design form for check job. Check job checks
a value against one or more conditions. The properties might not be in the most helpful order – but better than XML alone.
Previously however, when configuring an adhoc job using the bean element, the user was just presented with Swing’s basic text area where they could enter some XML. In Oddjob 1.2 there is now a field for a fully qualified Java Bean class name.
In Oddjob 1.1, the error was reported without the stack trace, but only after the designer had closed so the configuration was lost! Although I got into the habit of using notepad as a backup when making large configuration changes, this ‘feature’ still caused me endless irritation.
Oddjob Designer’s forms are still quite crude. Everything is text fields and Swing’s GridBag layout contributes it’s usual resize quirks, and there is no undo! However, I hope this new small feature provides a small tranquil clearing in the XML configuration jungle.