ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <K...@paranor.ch>
Subject RE: preferred way of using other tasks programatically
Date Wed, 17 Apr 2002 14:21:45 GMT
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.  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"));

I am also unsure about some things with your solution:

- How are the location and project fields set?
- A task expects that it's initialization steps (init(), addXXX(), setXXX(),
etc.) occur once only.  This requires great care from the caller side.

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

--
knut

> -----Original Message-----
> From: Jon Skeet [mailto:jon.skeet@peramon.com]
> Sent: Mittwoch, 17. April 2002 16:04
> To: Ant Developers List
> Subject: RE: preferred way of using other tasks programatically
> 
> 
> > I was wondering if someone could suggest a good way to make 
> > use of other
> > tasks from within a task.  I would for example like to use 
> the <mkdir>
> > functionality from within a custom task.  In the case of <mkdir> the
> > corresponding Java class only has an execute() method (and 
> a setDir()
> > method), which doesn't make it very straight forward or 
> > elegant.  So maybe
> > there is a preferred way to refactor tasks, which then allows 
> > me to use them
> > programatically.
> > 
> > I only mentioned <mkdir> to exemplify, I actually would like 
> > to use other
> > custom tasks programatically.  But it seems like it should be 
> > a quite common pattern to base a task on other tasks.
> 
> Continuing with mkdir as an example: is seems pretty 
> straightforward to me:
> 
> o Create the task
> o Configure it
> o Execute it
> 
> That's what Ant does, with more bits in between for 
> dependencies etc, so it should be fairly reliable.
> 
> What would you consider more straightforward?
> 
> Jon
> 
> --
> To unsubscribe, e-mail:   
<mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>

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