On Thu, 19 Jul 2001 01:08, [EMAIL PROTECTED] wrote: > On Wed, 18 Jul 2001, Peter Donald wrote: > > On Wed, 18 Jul 2001 17:17, [EMAIL PROTECTED] wrote: > > > Any half of the patch would help ( if I can load a group of tasks with > > > the same loader I can resolve my problem ), but I think it's nice to > > > use a single class loader for a certain classpath ( at lest for > > > taskdefs ). > > > > I am curious what you are using this for. Is it to keep state across task > > invocations or something else ? > > Not only. To keep state across tasks you can use "properties" ( since the > Hashtable is returned, you can store any object in it - if you want to ). > > I have a set of "cooperating tasks" - one is sending a http request, > few other are manipulating the response, another one is reporting > results. Doing it all in a single task is ugly. > > The problem is each task is in a different loader ( unless I put them in > CLASSPATH - and I hate that ), and they can't use information from each > other ( only "system" types can be saved ). > > I also prefer to use the task adapter and not extend Task directly ( or > use internal ant APIs, only the patterns ).
sounds reasonable and impossible todo in current ant ;) > > > BTW, what's the policy for "optional" tasks ? > > > > I am not sure we have a policy. What do you want to do ? ;) > > Can any commiter add a new optional task ? Is there a proposal/vote ( and > maybe a template for the proposal ) ? Depends on what it is I guess. Personally I just add it and wait for -1s if they occur ;) However what you are talking about (Http manipulation???) seems to be very close in purpose to cactus. So that could be a better place for that sort of stuff... Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
