Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 15378 invoked from network); 13 Jul 2002 15:56:26 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Jul 2002 15:56:26 -0000 Received: (qmail 5161 invoked by uid 97); 13 Jul 2002 15:56:40 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 5120 invoked by uid 97); 13 Jul 2002 15:56:39 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 5108 invoked by uid 98); 13 Jul 2002 15:56:38 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Sat, 13 Jul 2002 08:54:53 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Ant Developers List Subject: Re: My itches for 1.6 In-Reply-To: <5.1.0.14.2.20020713115912.01c0baa8@www.stocksoftware.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 13 Jul 2002, Peter Donald wrote: > At 03:01 PM 7/12/2002 -0700, you wrote: > >Not sure I understand what will brake. I'm not talking about putting > >ant implementation in a separate loader, like tomcat does - just > >have a small Bootstrap that creates an AntClassLoader and puts > >everything in lib/ in it ( like the shell is doing ). > > The sheel places them in the system classloader and thus a classloader like > > new URLClassLoader( new URL[] { myFile.toURL() } ); > > include the ant classes (as they are in system classloader). You realize this is wrong and such code will fail in a container environment. ( as general programming - for ant it may be ok ). Ok, would it be ok if the ant classes ( core, types, standard taskdefs ) are in the system loader, but the optional tasks are not ? That's even simpler to implement - just make sure optional.jar is not loaded by the shell, and load it as a first step in Project.init(), in an AntClassLoader. Are your tasks using something from optional.jar and assume it is in the system loader ? > >It is possible to put some jars in CLASSPATH ( like they were before ) > >if needed. > > The problem is that we have to place everything that currently exists in > ant in the system classloader if we want to maintain backwards > compatability. For future things we could create subclassloaders maybe. For future (1.7?) I would like the 'full' separation, with the xml parser and all the auxiliary classes in a paralel loader ( like the container loader in tomcat ), to allow tasks to use their own jaxp parsers. I think I can do that easily with a hook - so that ant itself will not be modified, but if people choose to use a classloader hook ( by installing something like the ProjectHelper2 in classpath or setting an option ) they get a 'hierarchical loader' similar with tomcat. I'm curently implementing this in ProjectHelper2 - so it'll actually work in ant1.5 as well. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: