« Eclipse does Swing! | Main | Users Group Presentation on Ant »

Inst.Ant gets a Christmas Gift

For those of you still following my weblog you all may remember that I had set Inst.Ant asided for a while while I pondered two problems, transactions and dynamic properties. I beleive I have solutions for both, but it may be a wile before I get to playing with them...

First on the issue of dynaimc properties, Costin has been a busy little bee over the holiday break, and has ported his changes relating to the dynamic properties support from his Embed proposal to the main ant line for 1.6. This means an end to evil hacks a d a more sensible solution to the ant call and properties problems. It may be a while before I get code written to exploit it, but as it is I need to wait a bit for PropertyHelper and friends to harden just a little. And then Ant 1.6 need so ship a FCS, which makes me shipping anything other than alpha quality code before that kinda useless. To paraphrase the greate M.Python "Inst.Ant's not dead (yet)."

Now about Transactions, how will I handle things throwing strange exceptions durring their executions (including ant build failure tasks)? What I plan to do is wrap all of the <do> targets into a try {} catch (Throwable t) {} block. It's a pretty wide scope but I want to catch errors too like OutOfMemory. I will then set an ant property holding the exception and set the execution order to undo. If the steps taken depend on failure or canceling or undoing then what that should be done on an error one can set the if= and unless= attributes to check for that standard property. The same will be done for cancel and (likely) normal forward back execution. If an error occurs in an undo the error will be re set, so there is the possibility of both a cancel and error flag being raised

So how does that affect transactions? It gives some greater control to the author to undo actions if stuff should fail, such as out of memory errors. While the granularity isn't directly to the level of individual task in the do/undo that can be fixed by the author splitting the do tasks to as many mutliples as are needed, to the level of one per do if that level of granularity is needed.

And in the interest of full disclosure, don't expect new code for a couple of weeks, at least. Family stuff and paintball is coming up, although I believe I have saciated my tase for NeverWinter Nights for a while longer.

Comments (1)

Dan Kearns:

On the subject of failure handling... it seems to me like you would need to extend the task dependency concept to support failure dependency targets as well. Then at least the target still "owns" its own world.

Otherwise, any target B that depends on target A would need to know to include the targets that recover from A as dependencies, and some other target that could halt or retry as well.

eg something like:

<target name="foo" failDepends="bar">
...
<die> or <restartFrom taskId="bas"/>
</target>

<target name="bar" depends="failA,failB"/>

<target name="failA" if="${OutOfMemoryError}"/>

Post a comment


About

This page contains a single entry from the blog posted on December 28, 2002 8:21 AM.

The previous post in this blog was Eclipse does Swing!.

The next post in this blog is Users Group Presentation on Ant.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33