ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bengt Bäverman <bengt.baver...@spray.se>
Subject Re: [PATCH] multithreading tasks
Date Mon, 19 Jun 2000 18:27:14 GMT
Is this not something that can be done in a normal taskdef? I don't see this
as necessary to include in the Ant application.

Bengt Bäverman
bengt.baverman@spray.se

----- Original Message ----- 
From: "James Duncan Davidson" <james.davidson@eng.sun.com>
To: <ant-dev@jakarta.apache.org>
Sent: Sunday, June 18, 2000 10:14 AM
Subject: Re: [PATCH] multithreading tasks


> on 5/28/00 8:58 AM, Conor MacNeill at conor@m64.com wrote:
> 
> > Attached is a fairly simple patch plus a new class to allow ant to run tasks
> > in separate threads. The motivation for this patch is to allow us to perform
> > unit testing in a relatively automated fashion. In our particular situation
> > we would like to have an ant target for testing which will start weblogic in
> > one thread and JUnit in another. Once JUnit completes its tests, weblogic
> > will be stopped and the target will complete by joining all outstanding
> > threads.
> 
> Has this been committed? I didn't see a commit message go out on it. In any
> case I'm -1 on this.
> 
> If concurency is needed for testing, then doing a test that that performs
> it's own parallelism at that level is fine, but building parallelism into
> Ant gets probelmatic fast. MT programming isn't *that* easy and I don't
> really think that projects should deal with it.
> 
> > Let me know what you think. If this is accepted, I plan two new small
> > taskdefs:- a sleep task and a join task.
> 
> Problem here is that now you are using tasks not to perform functionality,
> but as logical control. Sam has worked on me enough that I'm no longer
> totally freaked out about layering scripting into Ant, as long as that
> scripting isn't expressed in the XML. Expressing threading semantics in the
> XML is neat, but complicates things to a great degree.
> 
> I understand the motive -- parallelism on tests is a good thing, but I don't
> see why that functionality has to be genericized to this level.
> 
> .duncan
> 
> 


Mime
View raw message