> Looking at 'The life-cycle of a task' in
> http://jakarta.apache.org/ant/manual/develop.html 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");
mkdir.execute();
Jon
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
