On Fri, 24 May 2002, Peter Donald wrote: > On Fri, 24 May 2002 09:23, [EMAIL PROTECTED] wrote: > > The big question is - can we agree to make the default > > behavior 'reuse' - i.e. taskdef will allways use the same > > loader for the same classpath ? If we do, then I can remove > > the magic property and the attribute. Is it possible that someone is > > actually using the fact that <taskdef> will create a different class > > loader for each task ? I think it is a bug, but if it is considered a > > feature we'll have to preserve it. > > It is a feature not a bug unfortunately ;( Some people who have written tasks > that use statics used to re taskdef tasks to get a "clean" task prior to each > invocation. However I am not sure this works anymore because of changes that > Stefan made wrt overiding tasks etc? I dunno - Stefan ?
If this is indeed a feature, it should be documented as such. Nothing in the taskdef documentation implies it is going to create a new classloader for each task, and relying on this is bad. I think it's reasonable to expect from the docs that if you define a task and a type, you'll be able to use them togheter, and the fact that it doesn't can be considered bug. Supporting that ( even if not explicitely documented/specified ) is more imporant ( IMHO ) than supporting the separate loader ( also undocumented feature, and very likely to fail if files are in the CLASSPATH ). Also, making separate loader a feature would mean we require taskdef to create a classloader on each invocation - which is a dubious behavior ( at least for default ). Anyway - that's a different issue. The patch would preserve the old behavior by default. If we decide it was a bug, I'll just reverse it to support the old way if explicitely requested and default to loader reuse. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
