On Fri, 24 May 2002, Conor MacNeill wrote: > I guess Magesh needs to make a call on whether this should go into the > release.
Sure, but everyone else can -1 - and that's what I'm worried about :-) > Why not create a datatype for the loader > > <loader id="tomcat.loader"> > <classpath ... > </loader> > > and then ref in the taskdef/typedefs > > <taskdef> > <loader refid="tomcat.loader"/> > </taskdef> > > No need for magic properties or implicit sharing of loaders. Regarding 'magic' properties - the main reason is to allow a single build.xml file that works with both ant1.4 and ant1.5. I don't think the next release of tomcat can require ant1.5 and not work with 1.4. My main concern was to create the minimal ammount of change, both in build.xml ( for backward compat ) and as code. I think it's more of a bugfix, using tasks and types should work in any case. 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. Regarding your sugestion - a <loader> type will work without any change with taskdef ( since we use the object referenced by the id, if it is an AntClassLoader ). I will rename the attribute from reuseLoader="loader-id" to loaderRef="loader-id" to make it clear what it means, but creating the inner <loader> for taskdef seems like too bigger code change. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
