ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: preferred way of using other tasks programatically
Date Wed, 17 Apr 2002 15:58:49 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.

True, but the given lifecycle only specifies the lifecycle of a task when
it's beeing used directly by Ant, which isn't necessarily the way you would
want to use it programatically.  For example: If I develop a <loop> Task I
might want to reuse a task instance through the loops.  To do this I would
need to know whether the setXXX() will have any effect on subsequent calls
to execute() or not.  So I have to look at the source code and don't have
any guarantee that it will run with a new version of the task.

I believe there should be a more general lifecycle where it's stated what
calls a task requires and should expect.  This would make it more
straightforward to use programatically.

> > 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.

The given example is surely not a very good way to solve it.  This would
require many constructors for the different combinations of attributes and
subelements, or just one with possibly an awful lot of parameters.

> > 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.

Is there currently any class in Ant for this?

> > - 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();

Currently the interface of a task centers around the way it is used by Ant.
It would be great if the interface were a little bit more neutral, so that
it is easier to use programatically.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message