Return-Path: Delivered-To: apmail-ant-dev-archive@www.apache.org Received: (qmail 77599 invoked from network); 16 Sep 2003 13:13:32 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 16 Sep 2003 13:13:32 -0000 Received: (qmail 13166 invoked by uid 500); 16 Sep 2003 13:13:26 -0000 Delivered-To: apmail-ant-dev-archive@ant.apache.org Received: (qmail 13001 invoked by uid 500); 16 Sep 2003 13:13:25 -0000 Mailing-List: contact dev-help@ant.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 dev@ant.apache.org Received: (qmail 12988 invoked from network); 16 Sep 2003 13:13:25 -0000 Received: from unknown (HELO exchange.sun.com) (192.18.33.10) by daedalus.apache.org with SMTP; 16 Sep 2003 13:13:25 -0000 Received: (qmail 6698 invoked by uid 50); 16 Sep 2003 13:16:18 -0000 Date: 16 Sep 2003 13:16:18 -0000 Message-ID: <20030916131618.6697.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: dev@ant.apache.org Cc: Subject: DO NOT REPLY [Bug 23191] - need brief, specific documentation on including custom tasks in deployed apps X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.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 . 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=23191 need brief, specific documentation on including custom tasks in deployed apps ------- Additional Comments From dbikel@cis.upenn.edu 2003-09-16 13:16 ------- In Example 2 in the section http://ant.apache.org/manual/develop.html#writingowntask it mentions "Another way to add a task (more permanently), is to add the task name and implementing class name to the default.properties file in the org.apache.tools.ant.taskdefs package. Then you can use it as if it were a built-in task." This sentence is highly confusing: why would anyone want to extend ant and then modify a particular ant installation? It would allow you to build locally using the new, custom task, but it makes the project totally unportable. Also, using Example 1 (simply labeled "Example" in the docs) means that you must have precompiled your custom task before distributing your project. But with an extensible build tool that is itself undergoing development (not to mention the JDK itself), this seems dangerous. Example 2 seems to be the only good, portable method of including custom tasks in a project that you want to be portable, but the docs don't exactly make this clear. One simple thing that would go a long way would be to label "Example" and "Example 2" with more explanatory titles, such as "Including a pre-compiled custom task in your project" and "Using ant to bootstrap itself with custom tasks included in your project", or something to that effect (those are wordy, but perspicuous). If this is all clear in the latest CVS docs, then I sincerely apologize for creating this feature request. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org For additional commands, e-mail: dev-help@ant.apache.org