From ant-dev-return-16533-apmail-jakarta-ant-dev-archive=jakarta.apache.org@jakarta.apache.org Tue Aug 07 16:36:10 2001 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@jakarta.apache.org Received: (qmail 44521 invoked by uid 500); 7 Aug 2001 16:36:09 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: ant-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 44505 invoked from network); 7 Aug 2001 16:36:09 -0000 Message-ID: <045b01c11f60$1214d080$f5fa07d5@pete> From: "Stefan Reich" To: References: <005101c1120a$2c26ae70$f5fa07d5@pete> Subject: Re: [PATCH] Lazy task class loading Date: Tue, 7 Aug 2001 18:43:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.3018.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N Stefan, > OK, I'll admit that your reminder triggers this response (I shouldn't > be sitting here on front of the screen anyway, but that's a different > story). No problem, sometimes we all need two or more kicks until we do something *g* > I like the changes to Project, but the way you've implemented the Ant > task, it will only pass on the class names of already loaded tasks, > not the actual classes - this not only means you'll have to load them > once again in the subbuild if you need the same task, but also that > any custom classloader a user may have specified in will be > lost. > > As a result, tasks that used to work in the main build may throw a > ClassNotFoundException in the subbuild - or even worse be a different > implementation of the same class. I have to admit I'm not entirely firm with how Ant uses classloaders. Will the subbuild always have a different classloader? Won't it have the outer classloader as a parent and automatically inherit all classes loaded by the parent? Either way, it seems to me this problem will be solved if I just pass the contents of the TaskDefinitionHashtable as-is. Strings as Strings, Classes as Classes. If I'm wrong here, please stop me - otherwise, I'll make that change and submit a new patch. > And then you want to apply the same logic to data types as well 8-) Data types...? > Stefan -Stefan (hehe, if this conversation goes on people will be really confused about who said what)