Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 32803 invoked from network); 16 Dec 2002 13:36:35 -0000 Received: from exchange.sun.com (HELO nagoya.betaversion.org) (192.18.33.10) by daedalus.apache.org with SMTP; 16 Dec 2002 13:36:35 -0000 Received: (qmail 24464 invoked by uid 97); 16 Dec 2002 13:37:41 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 24436 invoked by uid 97); 16 Dec 2002 13:37:40 -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 24423 invoked by uid 98); 16 Dec 2002 13:37:40 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Subject: How to provide reusable ClassPaths in ANT Date: Mon, 16 Dec 2002 13:36:26 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F509C@london.cellectivity.com> X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-TNEF-Correlator: Thread-Topic: [PATCH] adds 'if'/'unless' to (CallTarget.java) Thread-Index: AcKVg+wI3JbRU49zS8m5uDAzS/pDFwPeSkLw From: "Jose Alberto Fernandez" To: "Ant Developers List" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N One of the things that most anoyed me of the current architecture of ANT if the way ClassPaths are managed during the build. Almost every task that can be passed a for finding classes, creates its own = AntClassLoader. As a consecuence ref-ids become incompatible very easily unless the = classes are all on the system classpath. By creating AntClassLoaders on those indifvidual tasks we are forcing = ANT to reload class definitions a lot, which has to slow things down, IMHO. I do not have a full solution (backward compatible and all), but would = like to propose doing some brainstorming to find a better way to do this (at = least on most cases). Here are some ideas I have been thinking about, for you guys to shread = to pieces: We continue declaring s the way we do, but allow to specify = caching of classloaders: ... The Path class will have a new methods: ClassLoader getCachedLoader(); void setCachedLoader(ClassLoader cl); these methods would be used by AntClassLoader to decide whether to = actually create a new ClassLoader of simply delegate to the cached one. So users = will continue to use things as they do today, and just the internals of this = implementations will know about this things. Of course, we still need some rules to decide when it is safe to use the = same classloader and when not. Given the configuration of the Path object. Any comments, ideas, do you guys thing there is any hope on something = like this to work? Jose Alberto -- To unsubscribe, e-mail: For additional commands, e-mail: