ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Skeet" <>
Subject RE: preferred way of using other tasks programatically
Date Wed, 17 Apr 2002 15:22:07 GMT
> Looking at 'The life-cycle of a task' in
> shows that 
> there are 10 steps, which I wouldn't consider very straightforward.

The essential ones are probably quite easy to automate though, and many aren't necessary in
many situations (eg calling addXXX when there aren't any such methods). Steps 6, 7, 8 and
9 are all the kind of things you'd want to set programmatically anyway.

> For 
> example having a
> constructor similar to the way it's referenced from a build 
> file would be
> easier.  For example:
> 	new Mkdir(new File("somedir"));

That's fine for a task with just one attribute, but is hugely unscalable.

> I am also unsure about some things with your solution:
> - How are the location and project fields set?

I missed that out before, but it shouldn't be too hard to write a toolkit bit of code which
sets the location and project of one task to be that of another.

> - A task expects that it's initialization steps (init(), 
> addXXX(), setXXX(),
> etc.) occur once only.  This requires great care from the caller side.

Great care? Not really - if you only want init() called once, only call it once, etc!

> Maybe a standardized way to invoke tasks programatically should be
> introduced?  Or a service that simplifies it?

There could certainly be something to standardise creating a task which is ready to programmatically
configure, ie taking care of steps 1-5. Beyond that, I don't think it needs much simplification:

Mkdir mkdir = new Mkdir();
UtilityClass.configureTaskOrWhatever (this, mkdir);
mkdir.setDir ("somedir");


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message