Return-Path: <anonymous@nagoya.betaversion.org>
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 86548 invoked from network); 13 Mar 2003 06:55:44 -0000
Received: from exchange.sun.com (192.18.33.10)
  by daedalus.apache.org with SMTP; 13 Mar 2003 06:55:44 -0000
Received: (qmail 17108 invoked by uid 50); 13 Mar 2003 06:57:35 -0000
Date: 13 Mar 2003 06:57:35 -0000
Message-ID: <20030313065735.17107.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: dev@ant.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 14553]  -
    Add support for a separate CLASSPATH
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14553>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14553

Add support for a separate CLASSPATH





------- Additional Comments From max@eos.dk  2003-03-13 06:57 -------
With 40++ build.xml files spread across many projects it is VERY worthwile to be 
able to specify an ANTCLASSPATH instead of having to keep the 40++ build.xml's 
uptodate when a new task is developed inhouse. And yes - ofcourse all 40++ 
build.xml files does not need to know about all the new tasks, but via the 
ANTCLASSPATH the job is a lot easier :)




If I have 5 custom tasks, each build.xml file has to specify 5 <taskdefs>, that 
is very "noisy" when it can be done much simpler IMHO :)




(or can one just do <taskdef resource="tasks.properties" classpath="${companyx.
anttasks.jar}"/> ...hmm, that will help ...isn't that a rather "new" feature ?).
.




Ok - I almost rest my case :) ... by using taskdef resource/file one can reduce 
it to a one-liner, but I still see it as a much cleaner way to specify the tasks 
available to ant from the "outside" instead of locally in each build.xml file